idnits 2.17.1 draft-ietf-geopriv-held-measurements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 6, 2010) is 4982 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 2059, but not defined == Missing Reference: '0-4' is mentioned on line 2059, but not defined == Missing Reference: '0-9' is mentioned on line 2059, but not defined == Missing Reference: '0-1' is mentioned on line 2059, but not defined == Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line 3195, but no explicit reference was found in the text == Unused Reference: 'RFC5808' is defined on line 3248, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-held-identity-extensions-04 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: March 10, 2011 September 6, 2010 7 Using Device-provided Location-Related Measurements in Location 8 Configuration Protocols 9 draft-ietf-geopriv-held-measurements-01 11 Abstract 13 A method is described by which a Device is able to provide location- 14 related measurement data to a LIS within a request for location 15 information. Location-related measurement information are 16 observations concerning properties related to the position of a 17 Device, which could be data about network attachment or about the 18 physical environment. When a LIS generates location information for 19 a Device, information from the Device can improve the accuracy of the 20 location estimate. A basic set of location-related measurements are 21 defined, including common modes of network attachment as well as 22 assisted Global Navigation Satellite System (GNSS) parameters. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 10, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Conventions used in this document . . . . . . . . . . . . . . 6 72 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7 73 4. Location-Related Measurement Data Types . . . . . . . . . . . 8 74 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9 75 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9 76 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9 77 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10 78 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11 80 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12 81 5. Location-Related Measurement Data Types . . . . . . . . . . . 15 82 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 15 83 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 16 84 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 16 85 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 19 86 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 20 87 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 23 88 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 23 89 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 25 90 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 26 92 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 27 93 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 27 94 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 28 95 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 28 96 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 29 97 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 29 98 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29 99 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 30 100 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 30 101 6.3. Measurement Data and Location URIs . . . . . . . . . . . . 30 102 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 31 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 31 105 7.1.1. Acquiring Location Information Without 106 Authorization . . . . . . . . . . . . . . . . . . . . 32 107 7.1.2. Extracting Network Topology Data . . . . . . . . . . . 33 108 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 33 109 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 34 110 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . . 35 111 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 36 112 7.2.1. Measurement Validation . . . . . . . . . . . . . . . . 37 113 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 37 114 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37 115 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38 116 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 39 117 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 39 118 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39 119 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 40 120 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40 121 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 41 122 7.2.5. Stateful Correlation of Location Requests . . . . . . 42 123 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42 124 8.1. Measurement Container Schema . . . . . . . . . . . . . . . 42 125 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 45 126 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 45 127 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48 128 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49 129 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 51 130 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54 131 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 57 132 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 58 133 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 134 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 60 135 9.2. URN Sub-Namespace Registration for 136 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61 137 9.3. URN Sub-Namespace Registration for 138 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62 139 9.4. URN Sub-Namespace Registration for 140 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63 141 9.5. URN Sub-Namespace Registration for 142 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 64 143 9.6. URN Sub-Namespace Registration for 144 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 64 145 9.7. URN Sub-Namespace Registration for 146 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 65 147 9.8. URN Sub-Namespace Registration for 148 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 66 149 9.9. URN Sub-Namespace Registration for 150 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 66 151 9.10. URN Sub-Namespace Registration for 152 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67 153 9.11. XML Schema Registration for Measurement Source Schema . . 68 154 9.12. XML Schema Registration for Measurement Container 155 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68 156 9.13. XML Schema Registration for Base Types Schema . . . . . . 68 157 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68 158 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 69 159 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69 160 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69 161 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 70 162 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 70 163 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 164 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 165 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70 166 11.2. Informative References . . . . . . . . . . . . . . . . . . 71 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 169 1. Introduction 171 A location configuration protocol (LCP) provides a means for a Device 172 to request information about its physical location from an access 173 network. A location information server (LIS) is the server that 174 provides location information; information that is available due to 175 the knowledge about the network and physical environment that is 176 available to the LIS. 178 As a part of the access network, the LIS is able to acquire 179 measurement results from network Devices within the network that are 180 related to Device location. The LIS also has access to information 181 about the network topology that can be used to turn measurement data 182 into location information. However, this information can be enhanced 183 with information acquired from the Device itself. 185 A Device is able to make observations about its network attachment, 186 or its physical environment. The location-related measurement data 187 might be unavailable to the LIS; alternatively, the LIS might be able 188 to acquire the data, but at a higher cost in time or otherwise. 189 Providing measurement data gives the LIS more options in determining 190 location, which could improve the quality of the service provided by 191 the LIS. Improvements in accuracy are one potential gain, but 192 improved response times and lower error rates are also possible. 194 This document describes a means for a Device to report location- 195 related measurement data to the LIS. Examples based on the HELD 196 [I-D.ietf-geopriv-http-location-delivery] location configuration 197 protocol are provided. 199 2. Conventions used in this document 201 The terms LIS and Device are used in this document in a manner 202 consistent with the usage in 203 [I-D.ietf-geopriv-http-location-delivery]. 205 This document also uses the following definitions: 207 Location Measurement: An observation about the physical properties 208 of a particular Device's network access. The result of a location 209 measurement--"location-related measurement data", or simply 210 "measurement data" given sufficient context--can be used to 211 determine the location of a Device. Location-related measurement 212 data does not identify a Device; measurement data can change with 213 time if the location of the Device also changes. 215 Location-related measurement data does not necessarily contain 216 location information directly, but it can be used in combination 217 with contextual knowledge of the network, or algorithms to derive 218 location information. Examples of location-related measurement 219 data are: radio signal strength or timing measurements, Ethernet 220 switch and port identifiers. 222 Location-related measurement data can be considered sighting 223 information, based on the definition in [RFC3693]. 225 Location Estimate: The result of location determination, a location 226 estimate is an approximation of where the Device is located. 227 Location estimates are subject to uncertainty, which arise from 228 errors in measurement results. 230 GNSS: Global Navigation Satellite System. A satellite-based system 231 that provides positioning and time information. For example, the 232 US Global Positioning System (GPS) or the European Galileo system. 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in [RFC2119]. 238 3. Location-Related Measurements in LCPs 240 This document defines a standard container for the conveyance of 241 location-related measurement parameters in location configuration 242 protocols. This is an XML container that identifies parameters by 243 type and allows the Device to provide the results of any measurement 244 it is able to perform. A set of measurement schemas are also defined 245 that can be carried in the generic container. 247 The simplest example of measurement data conveyance is illustrated by 248 the example message in Figure 1. This shows a HELD location request 249 message with an Ethernet switch and port measurement taken using LLDP 250 [IEEE.8021AB]. 252 253 civic 254 256 257 0a01003c 258 c2 259 260 261 262 Figure 1: HELD Location Request with Measurement Data 264 Measurement data that the LIS does not support or understand can be 265 ignored. The measurements defined in this document follow this rule; 266 extensions that could result in backward incompatibility MUST be 267 added as new measurement definitions rather than extensions to 268 existing types. 270 Multiple sets of measurement data, either of the same type or from 271 different sources can be included in the "measurements" element. See 272 Section 4.1.1 for details on repetition of this element. 274 Use of location-related measurement data is at the discretion of the 275 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to 276 reflect the method used. 278 Location-related measurement data need not be provided exclusively by 279 Devices. A third party location requester can request location 280 information using measurement data, if they are able and authorized. 281 There are privacy considerations relating to the use of measurements 282 by third parties, which are discussed in Section 6.4. 284 Location-related measurement data and its use presents a number of 285 security challenges. These are described in more detail in 286 Section 7. 288 4. Location-Related Measurement Data Types 290 A common container is defined for the expression of location 291 measurement data, as well as a simple means of identifying specific 292 types of measurement data for the purposes of requesting them. 294 The following example shows a measurement container with measurement 295 time and expiration time included. A WiFi measurement is enclosed. 297 300 301 302 00-12-F0-A0-80-EF 303 wlan-home 304 305 306 308 Figure 2: Measurement Example 310 4.1. Measurement Container 312 The "measurement" element is used to encapsulate measurement data 313 that is collected at a certain point in time. It contains time-based 314 attributes that are common to all forms of measurement data, and 315 permits the inclusion of arbitrary measurement data. 317 This container can be added to any request for location information, 318 such as a HELD location request 319 [I-D.ietf-geopriv-http-location-delivery]. 321 4.1.1. Time of Measurement 323 The "time" attribute records the time that the measurement or 324 observation was made. This time can be different to the time that 325 the measurement information was reported. Time information can be 326 used to populate a timestamp on the location result, or to determine 327 if the measurement information is used. 329 The "time" attribute is optional to avoid forcing an arbitrary choice 330 of timestamp for relatively static types of measurement (for 331 instance, the DSL measurements in Section 5.6) and for legacy Devices 332 that don't record time information (such as the Home Location 333 Register/Home Subscriber Server for cellular). However, time SHOULD 334 be provided whenever possible. 336 The "time" attribute is attached to the root "measurement" element. 337 If it is necessary to provide multiple sets of measurement data with 338 different times, multiple "measurement" elements SHOULD be provided. 340 4.1.2. Expiry Time on Location-Related Measurement Data 342 A Device is able to indicate an expiry time in the location 343 measurement using the "expires" attribute. Nominally, this attribute 344 indicates how long information is expected to be valid for, but it 345 can also indicate a time limit on the retention and use of the 346 measurement data. A Device can use this attribute to prevent the LIS 347 from retaining measurement data or limit the time that a LIS retains 348 this information. 350 Note: Movement of a Device might result in the measurement data 351 being invalidated before the expiry time. 353 The LIS MUST NOT keep location-related measurement data beyond the 354 time indicated in the "expires" attribute. 356 4.2. RMS Error and Number of Samples 358 Often a measurement is taken more than once over a period of time. 359 Reporting the average of a number of measurement results mitigates 360 the effects of random errors that occur in the measurement process. 362 Reporting each measurement individually can be the most effective 363 method of reporting multiple measurements. This is achieved by 364 providing multiple "measurement" elements for different times. 366 The alternative is to aggregate multiple measurements and report a 367 mean value across the set of measurements. Additional information 368 about the distribution of the results can be useful in determining 369 location uncertainty. 371 Two optional attributes are provided for certain measurement values: 373 rmsError: The root-mean-squared (RMS) error of the set of 374 measurement values used in calculating the result. RMS error is 375 expressed in the same units as the measurement, unless otherwise 376 stated. If an accurate value for RMS error is not known, this 377 value can be used to indicate an upper bound or estimate for the 378 RMS error. 380 samples: The number of samples that were taken in determining the 381 measurement value. If omitted, this value can be assumed to be a 382 very large value, so that the RMS error is an indication of the 383 standard deviation of the sample set. 385 For some measurement techniques, measurement error is largely 386 dependent on the measurement technique employed. In these cases, 387 measurement error is largely a product of the measurement technique 388 and not the specific circumstances, so RMS error does not need to be 389 actively measured. A fixed value MAY be provided for RMS error where 390 appropriate. 392 The "rmsError" and "samples" elements are added as attributes of 393 specific measurement data types. 395 4.2.1. Time RMS Error 397 Measurement of time can be significant in certain circumstances. The 398 GNSS measurements included in this document are one such case where a 399 small error in time can result in a large error in location. Factors 400 such as clock drift and errors in time sychronization can result in 401 small, but significant, time errors. Including an indication of the 402 quality of the time can be helpful. 404 An optional "timeError" attribute can be added to the "measurement" 405 element to indicate the RMS error in time. "timeError" indicates an 406 upper bound on the time RMS error in seconds. 408 The "timeError" attribute does not apply where multiple samples of a 409 measurement is taken over time. If multiple samples are taken, each 410 SHOULD be included in a different "measurement" element. 412 4.3. Measurement Request 414 A measurement request is used by a protocol peer to describe a set of 415 measurement data that it desires. A "measurementRequest" element is 416 defined that can be included in a protocol exchange. 418 For instance, a LIS can use a measurement request in HELD responses. 419 If the LIS is unable to provide location information, but it believes 420 that a particular measurement type would enable it to provide a 421 location, it can include a measurement request in an error response. 423 The "measurement" element of the measurement request identifies the 424 type of measurement that is requested. The "type" attribute of this 425 element indicates the type of measurement, as identified by an XML 426 qualified name. An optional "samples" attribute indicates how many 427 samples of the identified measurement are requested. 429 The "measurement" element can be repeated to request multiple (or 430 alternative) measurement types. 432 Additional XML content might be defined for a particular measurement 433 type that is used to further refine a request. These elements either 434 constrain what is requested or specify optional components of the 435 measurement data that are needed. These are defined along with the 436 specific measurement type. 438 In the HELD protocol, the inclusion of a measurement request in a 439 error response with a code of "locationUnknown" indicates that the 440 LIS believes that providing the indicated measurements would increase 441 the likelihood of a subsequent request being successful. 443 The following example shows a HELD error response that indicates that 444 WiFi measurement data would be useful if a later request were made. 445 Additional elements indicate that received signal strength for an 446 802.11n access point is requested. 448 450 Insufficient measurement data 451 454 455 n 456 wifi:rcpi 457 458 459 461 Figure 3 463 A measurement request that is included in other HELD messages has 464 undefined semantics and can be safely ignored. Other specifications 465 might define semantics for measurement requests under other 466 conditions. 468 4.4. Identifying Location Provenance 470 An extension is made to the PIDF-LO [RFC4119] that allows a location 471 recipient to identify the source (or sources) of location information 472 and the measurement data that was used to determine that location 473 information. 475 The "source" element is added to the "geopriv" element of the 476 PIDF-LO. This element does not identify specific entities. Instead, 477 it identifies the type of source. 479 The following types of measurement source are identified: 481 lis: Location information is based on measurement data that the LIS 482 or sources that it trusts have acquired. This label might be used 483 if measurement data provided by the Device has been completely 484 validated by the LIS. 486 device: Location information is based on measurement data that the 487 Device has provided to the LIS. 489 other: Location information is based on measurement data that a 490 third party has provided. This might be an authorized third party 491 that uses identity parameters 492 [I-D.ietf-geopriv-held-identity-extensions] or any other entity. 494 No assertion is made about the veracity of the measurement data from 495 sources other than the LIS. A combination of tags MAY be included to 496 indicate that measurement data from both sources was used. 498 For example, the first tuple of the following PIDF-LO indicates that 499 measurement data from a LIS and a device was combined to produce the 500 result, the second tuple was produced by the LIS alone. 502 508 509 510 511 512 513 7.34324 134.47162 514 515 850.24 516 517 518 519 520 OTDOA 521 lis device 522 523 524 525 526 527 528 529 530 7.34379 134.46484 531 532 9000 533 534 535 536 537 Cell 538 lis 539 540 541 542 544 5. Location-Related Measurement Data Types 546 This document defines location-related measurement data types for a 547 range of common network types. 549 All included measurement data definitions allow for arbitrary 550 extension in the corresponding schema. As new parameters that are 551 applicable to location determination are added, these can be added as 552 new XML elements in a unique namespace. Though many of the 553 underlying protocols support extension, creation of specific XML- 554 based extensions to the measurement format is favored over 555 accomodating protocol-specific extensions in generic containers. 557 5.1. LLDP Measurements 559 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent 560 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet, 561 WiFi, 802.16). These messages all contain identification information 562 for the sending node, which can be used to determine location 563 information. A Device that receives LLDP messages can report this 564 information as a location-related measurement to the LIS, which is 565 then able to use the measurement data in determining the location of 566 the Device. 568 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery 569 (LLDP-MED) [ANSI/TIA-1057] provide the ability to acquire location 570 information directly from an LLDP endpoint. Where this 571 information is available, it might be unnecessary to use any other 572 form of location configuration. 574 The Device MUST report the values directly as they were provided by 575 the adjacent node. Attempting to adjust or translate the type of 576 identifier is likely to cause the measurement data to be useless. 578 Where a Device has received LLDP messages from multiple adjacent 579 nodes, it should provide information extracted from those messages by 580 repeating the "lldp" element. 582 An example of an LLDP measurement is shown in Figure 4. This shows 583 an adjacent node (chassis) that is identified by the IP address 584 192.0.2.45 (hexadecimal c000022d) and the port on that node is 585 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 587 589 590 c000022d 591 a2 592 593 595 Figure 4: LLDP Measurement Example 597 IEEE 802 Devices that are able to obtain information about adjacent 598 network switches and their attachment to them by other means MAY use 599 this data type to convey this information. 601 5.2. DHCP Relay Agent Information Measurements 603 The DHCP Relay Agent Information option [RFC3046] provides 604 measurement data about the network attachment of a Device. This 605 measurement data can be included in the "dhcp-rai" element. 607 The elements in the DHCP relay agent information options are opaque 608 data types assigned by the DHCP relay agent. The three items are all 609 optional: circuit identifier ("circuit", [RFC3046]), remote 610 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier 611 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier 612 has an associated enterprise number [IANA.enterprise] as an XML 613 attribute. 615 617 618 ::ffff:192.0.2.158 619 108b 620 621 623 Figure 5: DHCP Relay Agent Information Measurement Example 625 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 626 4291 [RFC4291] IPv6 address. The enterprise number is specified as a 627 decimal integer. All other information is included verbatim from the 628 DHCP request in hexadecimal format. 630 5.3. 802.11 WLAN Measurements 632 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to 633 provide information about the access point (AP) that it is attached 634 to, or other WiFi points it is able to see. This is provided using 635 the "wifi" element, as shown in Figure 6, which shows a single 636 complete measurement for a single access point. 638 640 641 Intel(r)PRO/Wireless 2200BG 642 643 AB-CD-EF-AB-CD-EF 644 Example 645 example 646 5 647 648 649 -34.4 150.8 650 651 652 a 653 5 654 2 655 2 656 2.56e-9 657 658 23 659 5 660 -59 661 23 662 663 664 10 665 9 666 -98.5 667 7.5 668 669 670 671 673 Figure 6: 802.11 WLAN Measurement Example 675 A wifi element is made up of one or more access points, and an 676 optional "nicType" element. Each access point is described using the 677 "ap" element, which is comprised of the following fields: 679 bssid: The basic service set identifier. In an Infrastructure BSS 680 network, the bssid is the 48 bit MAC address of the access point. 682 The "verified" attribute of this element describes whether the 683 device has verified the MAC address or it authenticated the access 684 point or the network operating the access point (for example, a 685 captive portal accessed through the access point has been 686 authenticated). This attributes defaults to a value of "false" 687 when omitted. 689 name: The broadcast name for the access point. 691 ssid: The service set identifier for the wireless network served by 692 the access point. 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 introducted 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. 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 dB. 737 gain: The gain of the access point antenna reported by the access 738 point, in dB. 740 rcpi: The received channel power indicator for the access point 741 signal, as measured by the Device. This value SHOULD be in 742 units of dBm (with RMS error in dB). If power is measured in a 743 different fashion, the "dBm" attribute MUST be set to "false". 744 Signal strength reporting on current hardware uses a range of 745 different mechanisms; therefore, the value of the "nicType" 746 element SHOULD be included if the units are not known to be in 747 dBm and the value reported by the hardware should be included 748 without modification. This element includes optional 749 "rmsError" and "samples" attributes. 751 rsni: The received signal to noise indicator in dBm. This 752 element includes optional "rmsError" and "samples" attributes. 754 deviceSignal: Measurement information for the signal transmitted by 755 the device, as reported by the access point. This element 756 contains the same child elements as the "ap" element, with the 757 access point and Device roles reversed. 759 All elements are optional except for "bssid". 761 The "nicType" element is used to specify the make and model of the 762 wireless network interface in the Device. Different 802.11 chipsets 763 report measurements in different ways, so knowing the network 764 interface type aids the LIS in determining how to use the provided 765 measurement data. The content of this field is unconstrained and no 766 mechanisms are specified to ensure uniqueness. 768 5.3.1. Wifi Measurement Requests 770 Two elements are defined for requesting WiFi measurements in a 771 measurement request: 773 type: The "type" element identifies the desired type (or types that 774 are requested. 776 parameter: The "parameter" element identifies an optional 777 measurements are requested for each measured access point. An 778 element is identified by its qualified name. The optional 779 "context" parameter can be used to specify if an element is 780 included as a child of the "ap" or "device" elements; omission 781 indicates that it applies to both. 783 Multiple types or parameters can be requested by repeating either 784 element. 786 5.4. Cellular Measurements 788 Cellular Devices are common throughout the world and base station 789 identifiers can provide a good source of coarse location information. 790 This information can be provided to a LIS run by the cellar operator, 791 or may be provided to an alternative LIS operator that has access to 792 one of several global cell-id to location mapping databases. 794 A number of advanced location determination methods have been 795 developed for cellular networks. For these methods a range of 796 measurement parameters can be collected by the network, Device, or 797 both in cooperation. This document includes a basic identifier for 798 the wireless transmitter only; future efforts might define additional 799 parameters that enable more accurate methods of location 800 determination. 802 The cellular measurement set allows a Device to report to a LIS any 803 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10) 804 cells that it is able to observe. Cells are reported using their 805 global identifiers. All 3GPP cells are identified by public land 806 mobile network (PLMN), which is formed of mobile country code (MCC) 807 and mobile network code (MNC); specific fields are added for each 808 network type. All other values are decimal integers. 810 812 813 814 46520 815 80936424 816 817 818 46506 819 10736789 820 821 822 824 Long term evolution (LTE) cells are identified by a 28-bit cell 825 identifier (eucid). 827 Figure 7: Example LTE Cellular Measurement 829 831 832 833 46520 834 200065000 835 836 837 46506 838 1638332767 839 840 841 843 Universal mobile telephony service (UMTS) cells are identified by 844 radio network controller (rnc) and cell id (cid). 846 Figure 8: Example UMTS Cellular Measurement 848 850 851 852 46506 853 1638332767 854 855 856 858 Global System for Mobile communication (GSM) cells are identified by 859 local radio network controller (rnc) and cell id (cid). 861 Figure 9: Example GSM Cellular Measurement 863 865 866 867 47231589212 868 869 870 47231589213 871 872 873 875 Code division multiple access (CDMA) cells are not identified by 876 PLMN, instead these use network id (nid), system id (sid) and base 877 station id (baseid). 879 Figure 10: Example CDMA Cellular Measurement 881 In general a cellular Device will be attached to the cellular network 882 and so the notion of a serving cell exists. Cellular network also 883 provide overlap between neighbouring sites, so a mobile Device can 884 hear more than one cell. The measurement schema supports sending 885 both the serving cell and any other cells that the mobile might be 886 able to hear. In some cases, the Device may simply be listening to 887 cell information without actually attaching to the network, mobiles 888 without a SIM are an example of this. In this case the Device may 889 simply report cells it can hear without flagging one as a serving 890 cell. An example of this is shown in Figure 11. 892 894 895 896 46520 897 200065000 898 899 900 46506 901 1638332767 902 903 904 906 Figure 11: Example Observed Cellular Measurement 908 5.4.1. Cellular Measurement Requests 910 Two elements can be used in measurement requests for cellular 911 measurements: 913 type: A label indicating the type of identifier to provide: one of 914 "gsm", "umts", "lte", or "cdma". 916 network: The network portion of the cell identifier. For 3GPP 917 networks, this is the combination of MCC and MNC; for CDMA, this 918 is the network identifier. 920 Multiple identifier types or networks can be identified by repeating 921 either element. 923 5.5. GNSS Measurements 925 GNSS use orbiting satellites to transmit signals. A Device with a 926 GNSS receiver is able to take measurements from the satellite 927 signals. The results of these measurements can be used to determine 928 time and the location of the Device. 930 Determining location and time in autonomous GNSS receivers follows 931 three steps: 933 Signal acquisition: During the signal acquisition stage, the 934 receiver searches for the repeating code that is sent by each GNSS 935 satellite. Successful operation typically requires measurement 936 data for a minimum of 5 satellites. At this stage, measurement 937 data is available to the Device. 939 Navigation message decode: Once the signal has been acquired, the 940 receiver then receives information about the configuration of the 941 satellite constellation. This information is broadcast by each 942 satellite and is modulated with the base signal at a low rate; for 943 instance, GPS sends this information at about 50 bits per second. 945 Calculation: The measurement data is combined with the data on the 946 satellite constellation to determine the location of the receiver 947 and the current time. 949 A Device that uses a GNSS receiver is able to report measurements 950 after the first stage of this process. A LIS can use the results of 951 these measurements to determine a location. In the case where there 952 are fewer results available than the optimal minimum, the LIS might 953 be able to use other sources of measurement information and combine 954 these with the available measurement data to determine a position. 956 Note: The use of different sets of GNSS _assistance data_ can 957 reduce the amount of time required for the signal acquisition 958 stage and obviate the need for the receiver to extract data on the 959 satellite constellation. Provision of assistance data is outside 960 the scope of this document. 962 Figure 12 shows an example of GNSS measurement data. The measurement 963 shown is for the GPS system and includes measurement data for three 964 satellites only. 966 968 970 971 499.9395 972 0.87595747 973 45 974 975 976 378.2657 977 0.56639479 978 52 979 980 981 -633.0309 982 0.57016835 983 48 984 985 986 988 Figure 12: Example GNSS Measurement 990 Each "gnss" element represents a single set of GNSS measurement data, 991 taken at a single point in time. Measurements taken at different 992 times can be included in different "gnss" elements to enable 993 iterative refinement of results. 995 GNSS measurement parameters are described in more detail in the 996 following sections. 998 5.5.1. GNSS System and Signal 1000 The GNSS measurement structure is designed to be generic and to apply 1001 to different GNSS types. Different signals within those systems are 1002 also accounted for and can be measured separately. 1004 The GNSS type determines the time system that is used. An indication 1005 of the type of system and signal can ensure that the LIS is able to 1006 correctly use measurements. 1008 Measurements for multiple GNSS types and signals can be included by 1009 repeating the "gnss" element. 1011 This document creates an IANA registry for GNSS types. Two satellite 1012 systems are registered by this document: GPS and Galileo. Details 1013 for the registry are included in Section 9.1. 1015 5.5.2. Time 1017 Each set of GNSS measurements is taken at a specific point in time. 1018 The "time" attribute is used to indicate the time that the 1019 measurement was acquired, if the receiver knows how the time system 1020 used by the GNSS relates to UTC time. 1022 Alternative to (or in addition to) the measurement time, the 1023 "gnssTime" element MAY be included. The "gnssTime" element includes 1024 a relative time in milliseconds using the time system native to the 1025 satellite system. For the GPS satellite system, the "gnssTime" 1026 element includes the time of week in milliseconds. For the Galileo 1027 system, the "gnssTime" element includes the time of day in 1028 milliseconds. 1030 The accuracy of the time measurement provided is critical in 1031 determining the accuracy of the location information derived from 1032 GNSS measurements. The receiver SHOULD indicate an estimated time 1033 error for any time that is provided. An RMS error can be included 1034 for the "gnssTime" element, with a value in milliseconds. 1036 5.5.3. Per-Satellite Measurement Data 1038 Multiple satellites are included in each set of GNSS measurements 1039 using the "sat" element. Each satellite is identified by a number in 1040 the "num" attribute. The satellite number is consistent with the 1041 identifier used in the given GNSS. 1043 Both the GPS and Galileo systems use satellite numbers between 1 and 1044 64. 1046 The GNSS receiver measures the following parameters for each 1047 satellite: 1049 doppler: The observed Doppler shift of the satellite signal, 1050 measured in meters per second. This is converted from a value in 1051 Hertz by the receiver to allow the measurement to be used without 1052 knowledge of the carrier frequency of the satellite system. This 1053 value includes an optional RMS error attribute, also measured in 1054 meters per second. 1056 codephase: The observed code phase for the satellite signal, 1057 measured in milliseconds. This is converted from a value in chips 1058 or wavelengths. Increasing values indicate increasing 1059 pseudoranges. This value includes an optional RMS error 1060 attribute, also measured in milliseconds. 1062 cn0: The signal to noise ratio for the satellite signal, measured in 1063 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 1064 dB-Hz. 1066 mp: An estimation of the amount of error that multipath signals 1067 contribute in metres. This parameter is optional. 1069 cq: An indication of the carrier quality. Two attributes are 1070 included: "continuous" may be either "true" or "false"; direct may 1071 be either "direct" or "inverted". This parameter is optional. 1073 adr: The accumulated Doppler range, measured in metres. This 1074 parameter is optional and is not necessary unless multiple sets of 1075 GNSS measurements are provided. 1077 All values are converted from measures native to the satellite system 1078 to generic measures to ensure consistency of interpretation. Unless 1079 necessary, the schema does not constrain these values. 1081 5.5.4. GNSS Measurement Requests 1083 Measurement requests can include a "gnss" element, which includes the 1084 "system" and "signal" attributes. Multiple elements can be included 1085 to indicate a requests for GNSS measurements from multiple systems or 1086 signals. 1088 5.6. DSL Measurements 1090 Digital Subscriber Line (DSL) networks rely on a range of network 1091 technology. DSL deployments regularly require cooperation between 1092 multiple organizations. These fall into two broad categories: 1093 infrastructure providers and Internet service providers (ISPs). 1094 Infrastructure providers manage the bulk of the physical 1095 infrastructure including cabling. End users obtain their service 1096 from an ISP, which manages all aspects visible to the end user 1097 including IP address allocation and operation of a LIS. See 1098 [DSL.TR025] and [DSL.TR101] for further information on DSL network 1099 deployments. 1101 Exchange of measurement information between these organizations is 1102 necessary for location information to be correctly generated. The 1103 ISP LIS needs to acquire location information from the infrastructure 1104 provider. However, the infrastructure provider has no knowledge of 1105 Device identifiers, it can only identify a stream of data that is 1106 sent to the ISP. This is resolved by passing measurement data 1107 relating to the Device to a LIS operated by the infrastructure 1108 provider. 1110 5.6.1. L2TP Measurements 1112 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the 1113 infrastructure provider and the ISP. The infrastructure provider LIS 1114 requires measurement data that identifies a single L2TP tunnel, from 1115 which it can generate location information. Figure 13 shows an 1116 example L2TP measurement. 1118 1120 1121 1122 192.0.2.10 1123 192.0.2.61 1124 528 1125 1126 1127 1129 Figure 13: Example DSL L2TP Measurement 1131 5.6.2. RADIUS Measurements 1133 When authenticating network access, the infrastructure provider might 1134 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 1135 Access Node (AN). These messages provide the ISP RADIUS server with 1136 an identifier for the DSLAM or AN, plus the slot and port that the 1137 Device is attached on. These data can be provided as a measurement, 1138 which allows the infrastructure provider LIS to generate location 1139 information. 1141 The format of the AN, slot and port identifiers are not defined in 1142 the RADIUS protocol. Slot and port together identify a circuit on 1143 the AN, analogous to the circuit identifier in [RFC3046]. These 1144 items are provided directly, as they were in the RADIUS message. An 1145 example is shown in Figure 14. 1147 1149 1150 AN-7692 1151 3 1152 06 1153 1154 1156 Figure 14: Example DSL RADIUS Measurement 1158 5.6.3. Ethernet VLAN Tag Measurements 1160 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 1161 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 1162 used to identify the incoming residential circuit, while the S-TAG is 1163 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 1164 be used to identify a single point of network attachment. An example 1165 is shown in Figure 15. 1167 1169 1170 613 1171 1097 1172 1173 1175 Figure 15: Example DSL VLAN Tag Measurement 1177 Alternatively, the C-TAG can be replaced by data on the slot and port 1178 that the Device is attached to. This information might be included 1179 in RADIUS requests that are proxied from the infrastructure provider 1180 to the ISP RADIUS server. 1182 5.6.4. ATM Virtual Circuit Measurements 1184 An ATM virtual circuit can be employed between the ISP and 1185 infrastructure provider. Providing the virtual port ID (VPI) and 1186 virtual circuit ID (VCI) for the virtual circuit gives the 1187 infrastructure provider LIS the ability to identify a single data 1188 stream. A sample measurement is shown in Figure 16. 1190 1192 1193 55 1194 6323 1195 1196 1198 Figure 16: Example DSL ATM Measurement 1200 6. Privacy Considerations 1202 Location-related measurement data can be as privacy sensitive as 1203 location information. 1205 Measurement data is effectively equivalent to location information if 1206 the contextual knowledge necessary to generate one from the other is 1207 readily accessible. Even where contextual knowledge is difficult to 1208 acquire, there can be no assurance that an authorized recipient of 1209 the contextual knowledge is also authorized to receive location 1210 information. 1212 In order to protect the privacy of the subject of location-related 1213 measurement data, this implies that measurement data is protected 1214 with the same degree of protection as location information. 1216 6.1. Measurement Data Privacy Model 1218 It is less desirable to distribute measurement data in the same 1219 fashion as location information. Measurement data is less useful to 1220 location recipients than location information. Therefore, a simple 1221 distribution model is desirable. 1223 In this simple model, the Device is the only entity that is able to 1224 distribute measurement data. To use an analogy from the GEOPRIV 1225 architecture, the Device - as the Location Generator (or the 1226 Measurement Data Generator) - is the sole entity that can assume the 1227 roles of Rule Maker and Location Server. 1229 No entity can redistribute measurement data. The Device directs 1230 other entities in how measurement data is used and retained. 1232 6.2. LIS Privacy Requirements 1234 A LIS MUST NOT reveal location-related measurement data or location 1235 information based on measurement data to any other entity unless 1236 directed to do so by the Device. 1238 By adding measurement data to a request for location information, the 1239 Device implicitly grants permission for the LIS to generate the 1240 requested location information using the measurement data. 1241 Permission to use this data for any other purpose is not implied. 1243 As long as measurement data is only used in serving the request that 1244 contains it, rules regarding data retention are not necessary. A LIS 1245 MUST discard location-related measurement data after servicing a 1246 request, unless the Device grants permission to use that information 1247 for other purposes. 1249 6.3. Measurement Data and Location URIs 1251 A LIS MAY use measurement data provided by the Device to serve 1252 requests to location URIs, if the Device permits it. A Device 1253 permits this by including measurement data in a request that 1254 explcitly requests a location URI. By requesting a location URI, the 1255 Device grants permission for the LIS to use the measurement data in 1256 serving requests to that URI. 1258 Note: In HELD, the "any" type is not an explicit request for a 1259 location URI, though a location URI might be provided. 1261 The usefulness of measurement data that is provided in this fashion 1262 is limited. The measurement data is only valid at the time that it 1263 was acquired by the Device. At the time that a request is made to a 1264 location URI, the Device might have moved, rendering the measurement 1265 data incorrect. 1267 A Device is able to explicitly limit the time that a LIS retains 1268 measurement data by adding an expiry time to the measurement data, 1269 see Section 4.1.2. 1271 6.4. Third-Party-Provided Measurement Data 1273 An authorized third-party request for the location of a Device (see 1274 [I-D.ietf-geopriv-held-identity-extensions]) can include location- 1275 related measurement data. This is possible where the third-party is 1276 able to make observations about the Device. 1278 A third-party that provides measurement data MUST be authorized to 1279 provide the specific measurement for the identified device. A third- 1280 party MUST either be trusted by the LIS for the purposes of providing 1281 measurement data of the provided type, or the measurement data MUST 1282 be validated (see Section 7.2.1) before being used. 1284 How a third-party authenticates its identity or gains authorization 1285 to use measurement data is not covered by this document. 1287 7. Security Considerations 1289 Use of location-related measurement data has privacy considerations 1290 that are discussed in Section 6. 1292 7.1. Threat Model 1294 The threat model for location-related measurement data concentrates 1295 on the Device providing falsified, stolen or incorrect measurement 1296 data. 1298 A Device that provides location location-related measurement data 1299 might use data to: 1301 o acquire the location of another Device, without authorization; 1303 o extract information about network topology; or 1305 o coerce the LIS into providing falsified location information based 1306 on the measurement data. 1308 Location-related measurement data describes the physical environment 1309 or network attachment of a Device. A third party adversary in the 1310 proximity of the Device might be able to alter the physical 1311 environment such that the Device provides measurement data that is 1312 controlled by the third party. This might be used to indirectly 1313 control the location information that is derived from measurement 1314 data. 1316 7.1.1. Acquiring Location Information Without Authorization 1318 Requiring authorization for location requests is an important part of 1319 privacy protections of a location protocol. A location configuration 1320 protocol usually operates under a restricted policy that allows a 1321 requester to obtain their own location. HELD identity extensions 1322 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to 1323 be authorized, conditional on a Rule Maker providing sufficient 1324 authorization. 1326 The intent of these protections is to ensure that a location 1327 recipient is authorized to acquire location information. Location- 1328 related measurement data could be used by an attacker to circumvent 1329 such authorization checks if the association between measurement data 1330 and Target Device is not validated by a LIS. 1332 A LIS can be coerced into providing location information for a Device 1333 that a location recipient is not authorized to receive. A request 1334 identifies one Device (implicitly or explicitly), but measurement 1335 data is provided for another Device. If the LIS does not check that 1336 the measurement data is for the identified Device, it could 1337 incorrectly authorize the request. 1339 By using unvalidated measurement data to generate a response, the LIS 1340 provides information about a Device without appropriate 1341 authorization. 1343 The feasibility of this attack depends on the availability of 1344 information that links a Device with measurement data. In some 1345 cases, measurement data that is correlated with a target is readily 1346 available. For instance, LLDP measurements (Section 5.1) are 1347 broadcast to all nodes on the same network segment. An attacker on 1348 that network segment can easily gain measurement data that relates a 1349 Device with measurements. 1351 For some types of measurement data, it's necessary for an attacker to 1352 know the location of the target in order to determine what 1353 measurements to use. This attack is meaningless for types of 1354 measurement data that require that the attacker first know the 1355 location of the target before measurement data can be acquired or 1356 fabricated. GNSS measurements (Section 5.5) share this trait with 1357 many wireless location determination methods. 1359 7.1.2. Extracting Network Topology Data 1361 Allowing requests with measurements might be used to collect 1362 information about a network topology. This is possible if requests 1363 containing measurements are permitted. 1365 Network topology can be considered sensitive information by a network 1366 operator for commercial or security reasons. While it is impossible 1367 to completely prevent a Device from acquiring some knowledge of 1368 network topology if a location service is provided, a network 1369 operator might desire to limit how much of this information is made 1370 available. 1372 Mapping a network topology does not require that an attacker be able 1373 to associate measurement data with a particular Device. If a 1374 requester is able to try a number of measurements, it is possible to 1375 acquire information about network topology. 1377 It is not even necessary that the measurements are valid; random 1378 guesses are sufficient, provided that there is no penalty or cost 1379 associated with attempting to use the measurements. 1381 7.1.3. Lying By Proxy 1383 Location information is a function of its inputs, which includes 1384 measurement data. Thus, falsified measurement data can be used to 1385 alter the location information that is provided by a LIS. 1387 Some types of measurement data are relatively easy to falsify in a 1388 way that the resulting location information to be selected with 1389 little or no error. For instance, GNSS measurements are easy to use 1390 for this purpose because all the contextual information necessary to 1391 calculate a position using measurements is broadcast by the 1392 satellites [HARPER]. 1394 An attacker that falsifies measurement data gains little if they are 1395 the only recipients of the result. The attacker knows that the 1396 location information is bad. The attacker only gains if the 1397 information can somehow be attributed to the LIS by another location 1398 recipient. 1400 A recipient might evaluate the trustworthiness of the location 1401 information based on the credibility of its source. By coercing the 1402 LIS into providing falsified location information, any credibility 1403 that the LIS might have - that the attacker does not - is gained by 1404 the attacker. 1406 A third-party that is reliant on the integrity of the location 1407 information might base an evaluation of the credibility of the 1408 information on the source of the information. If that third party is 1409 able to attribute location information to the LIS, then an attacker 1410 might gain. 1412 Location information that is provided to the Device without any means 1413 to identify the LIS as its source is not subject to this attack. The 1414 Device is identified as the source of the data when it distributes 1415 the location information to location recipients. 1417 An attacker gains if they are able to coerce the LIS into providing 1418 location information based on falsified measurement data and that 1419 information can be attributed to the LIS. 1421 Location information is attributed to the LIS either through the use 1422 of digital signatures or by having the location recipient directly 1423 interact with the LIS. A LIS that digitally signs location 1424 information becomes identifiable as the source of the data. 1425 Similarly, the LIS is identified as a source of data if a location 1426 recipient acquires information directly from a LIS using a location 1427 URI. 1429 7.1.4. Measurement Replay 1431 The value of some measured properties do not change over time for a 1432 single location. This allows for simple replay attacks, where an 1433 attacker acquires measurements that can later be used without being 1434 detected as being invalid. 1436 Measurement data is frequently an observation of an time-invariant 1437 property of the environment at the subject location. For 1438 measurements of this nature, nothing in the measurement itself is 1439 sufficient proof that the Device is present at the resulting 1440 location. Measurement data might have been previously acquired and 1441 reused. 1443 For instance, the identity of a radio transmitter, if broadcast by 1444 that transmitter, can be collected and stored. An attacker that 1445 wishes it known that they exist at a particular location, can claim 1446 to observe this transmitter at any time. Nothing inherent in the 1447 claim reveals it to be false. 1449 For properties of a network, time-invariance is often directly as a 1450 result of the practicalities of operating the network. Limiting the 1451 changes to a network ensures greater consistency of service. A 1452 largely static network also greatly simplifies the data management 1453 tasks involved with providing a location service. 1455 7.1.5. Environment Spoofing 1457 Some types of measurement data can be altered or influenced by a 1458 third party so that a Device. If it is possible for a third party to 1459 alter the measured phenomenon, then any location information that is 1460 derived from this data can be indirectly influenced. 1462 Altering the environment in this fashion might not require 1463 involvement with either Device or LIS. Measurement that is passive - 1464 where the Device observes a signal or other phenomenon without direct 1465 interaction - are most susceptible to alteration by third parties. 1467 Measurement of radio signal characteristics is especially vulnerable 1468 since an adversary need only be in the general vicinity of the Device 1469 and be able to transmit a signal. For instance, a GNSS spoofer is 1470 able to produce fake signals that claim to be transmitted by any 1471 satellite or set of satellites (see [GPS.SPOOF]). 1473 Measurements that require direct interaction increases the complexity 1474 of the attack. For measurements relating to the communication 1475 medium, a third party cannot avoid direct interaction, they need only 1476 be on the comminications path (that is, man in the middle). 1478 Even if the entity that is interacted with is authenticated, this 1479 does not provide any assurance about the integrity of measurement 1480 data. For instance, the Device might authenticate the identity of a 1481 radio transmitter through the use of cryptographic means and obtain 1482 signal strength measurements for that transmitter. Radio signal 1483 strength is trivial for an attacker to increase simply by receiving 1484 and amplifying the raw signal; it is not necessary for the attacker 1485 to be able to understand the signal content. 1487 Note: This particular "attack" is more often completely legitimate. 1488 Radio repeaters are commonplace mechanism used to increase radio 1489 coverage. 1491 Attacks that rely on altering the observed environment of a Device 1492 require countermeasures that affect the measurement process. For 1493 radio signals, countermeasures could include the use of authenticated 1494 signals, altered receiver design. In general, countermeasures are 1495 highly specific to the individual measurement process. An exhaustive 1496 discussion of these issues is left to the relevant literature for 1497 each measurement technology. 1499 A Device that provides measurement data is assumed to be responsible 1500 for applying appropriate countermeasures against this type of attack. 1502 For a Device that is the ultimate recipient of location information 1503 derived from measurement data, a LIS might choose to provide location 1504 information without any validation. The responsibility for ensuring 1505 the veracity of the measurement data lies with the Device. 1507 Measurement data that is susceptible to this sort of influence MUST 1508 be treated as though it were produced by an untrusted Device for 1509 those cases where a location recipient might attribute the location 1510 information to the LIS. Such measurement data MUST be subjected to 1511 the same validation as for other types of attacks that rely on 1512 measurement falsification. 1514 Note: Altered measurement data might be provided by a Device that 1515 has no knowledge of the alteration. Thus, an otherwise trusted 1516 Device might still be an unreliable source of measurement data. 1518 7.2. Mitigation 1520 The following measures can be applied to limit or prevent attacks. 1521 The effectiveness of each depends on the type of measurement data and 1522 how that measurement data is acquired. 1524 Two general approaches are identified for dealing with untrusted 1525 measurement data: 1527 1. Require independent validation of measurement data or the 1528 location information that is produced. 1530 2. Identify the types of sources that provided the measurement data 1531 that location information was derived from. 1533 This section goes into more detail on the different forms of 1534 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The 1535 impact of attributing location information to sources is discussed in 1536 more detail in Section 7.2.4. 1538 7.2.1. Measurement Validation 1540 Detecting that measurement data has been falsified is difficult in 1541 the absence of integrity mechanisms. 1543 Independent confirmation of the veracity of measurement data ensures 1544 that the measurement is accurate and that it applies to the correct 1545 Device. By gathering the same measurement data from a trusted and 1546 independent source, the LIS is able to check that the measurement 1547 data is correct. 1549 Measurement information might contain no inherent indication that it 1550 is falsified. On the contrary, it can be difficult to obtain 1551 information that would provide any degree of assurance that the 1552 measurement device is physically at any particular location. 1553 Measurements that are difficult to verify require other forms of 1554 assurance before they can be used. 1556 7.2.1.1. Effectiveness 1558 Measurement validation MUST be used if measurement data for a 1559 particular Device can be easily acquired by unauthorized location 1560 recipients, as described in Section 7.1.1. This prevents 1561 unauthorized access to location information using measurement data. 1563 Validation of measurement data can be significantly more effective 1564 than independent acquisition of the same. For instance, a Device in 1565 a large Ethernet network could provide a measurement indicating its 1566 point of attachment using LLDP measurements. For a LIS, acquiring 1567 the same measurement data might require a request to all switches in 1568 that network. With the measurement data, validation can target the 1569 identified switch with a specific query. 1571 Validation is effective in identifying falsified measurement data 1572 (Section 7.1.3), including attacks involving replay of measurement 1573 data (Section 7.1.4). Validation also limits the amount of network 1574 topology information (Section 7.1.2) made available to Devices to 1575 that portion of the network topology that they are directly attached. 1577 Measurement validation has no effect if the underlying effect is 1578 being spoofed (Section 7.1.5). 1580 7.2.1.2. Limitations (Unique Observer) 1582 A Device is often in a unique position to make a measurement. It 1583 alone occupies the point in space-time that the location 1584 determination process seeks to determine. The Device becomes a 1585 unique observer for a particular property. 1587 The ability of the Device to become a unique observer makes the 1588 Device invaluable to the location determination process. As a unique 1589 observer, it also makes the claims of a Device difficult to validate 1590 and easily to spoof. 1592 As long as no other entity is capable of making the same 1593 measurements, there is also no other entity that can independently 1594 check that the measurements are correct and applicable to the Device. 1595 A LIS might be unable to validate all or part of the measurement data 1596 it receives from a unique observer. For instance, a signal strength 1597 measurement of the signal from a radio tower cannot be validated 1598 directly. 1600 Some portion of the measurement data might still be independently 1601 verified, even if all information cannot. In the previous example, 1602 the radio tower might be able to provide verification that the Device 1603 is present if it is able to observe a radio signal sent by the 1604 Device. 1606 If measurement data can only be partially validated, the extent to 1607 which it can be validated determines the effectiveness of validation 1608 against these attacks. 1610 The advantage of having the Device as a unique observer is that it 1611 makes it difficult for an attacker to acquire measurements without 1612 the assistance of the Device. Attempts to use measurements to gain 1613 unauthorized access to measurement data (Section 7.1.1) are largely 1614 ineffectual against a unique observer. 1616 7.2.2. Location Validation 1618 Location information that is derived from location-related 1619 measurement data can also be verified against trusted location 1620 information. Rather than validating inputs to the location 1621 determination process, suspect locations are identified at the output 1622 of the process. 1624 Trusted location information is acquired using sources of measurement 1625 data that are trusted. Untrusted location information is acquired 1626 using measurement data provided from untrusted sources, which might 1627 include the Device. These two locations are compared. If the 1628 untrusted location agrees with the trusted location, the untrusted 1629 location information is used. 1631 Algorithms for the comparison of location information are not 1632 included in this document. However, a simple comparison for 1633 agreement might require that the untrusted location be entirely 1634 contained within the uncertainty region of the trusted location. 1636 There is little point in using a less accurate, less trusted 1637 location. Untrusted location information that has worse accuracy 1638 than trusted information can be immediately discarded. There are 1639 multiple factors that affect accuracy, uncertainty and currency being 1640 the most important. How location information is compared for 1641 accuracy is not defined in this document. 1643 7.2.2.1. Effectiveness 1645 Location validation limits the extent to which falsified - or 1646 erroneous - measurement data can cause an incorrect location to be 1647 reported. 1649 Location validation can be more efficient than validation of inputs, 1650 particularly for a unique observer (Section 7.2.1.2). 1652 Validating location ensures that the Device is at or near the 1653 resulting location. Location validation can be used to limit or 1654 prevent all of the attacks identified in this document. 1656 7.2.2.2. Limitations 1658 The trusted location that is used for validation is always less 1659 accurate than the location that is being checked. The amount by 1660 which the untrusted location is more accurate, is the same amount 1661 that an attacker can exploit. 1663 For example, a trusted location might indicate a five kilometer 1664 radius uncertainty region. An untrusted location that describes a 1665 100 meter uncertainty within the larger region might be accepted as 1666 more accurate. An attacker might still falsify measurement data to 1667 select any location within the larger uncertainty region. While the 1668 100 meter uncertainty that is reported seems more accurate, a 1669 falsified location could be anywhere in the five kilometer region. 1671 Where measurement data might have been falsified, the actual 1672 uncertainty is effectively much higher. Local policy might allow 1673 differing degrees of trust to location information derived from 1674 untrusted measurement data. This might not be a boolean operation 1675 with only two possible outcomes: untrusted location information might 1676 be used entirely or not at all, or it could be combined with trusted 1677 location information with the degree to which each contributes based 1678 on a value set in local policy. 1680 7.2.3. Supporting Observations 1682 Replay attacks using previously acquired measurement data are 1683 particularly hard to detect without independent validation. Rather 1684 than validate the measurement data directly, supplementary data might 1685 be used to validate measurements or the location information derived 1686 from those measurements. 1688 These supporting observations could be used to convey information 1689 that provides additional assurance that the Device was acquired at a 1690 specific time and place. In effect, the Device is requested to 1691 provide proof of its presence at the resulting location. 1693 For instance, a Device that measures attributes of a radio signal 1694 could also be asked to provide a sample of the measured radio signal. 1695 If the LIS is able to observe the same signal, the two observations 1696 could be compared. Providing that the signal cannot be predicted in 1697 advance by the Device, this could be used to support the claim that 1698 the Device is able to receive the signal. Thus, the Device is likely 1699 to be within the range that the signal is transmitted. A LIS could 1700 use this to attribute a higher level of trust in the associated 1701 measurement data or resulting location. 1703 7.2.3.1. Effectiveness 1705 The use of supporting observations is limited by the ability of the 1706 LIS to acquire and validate these observations. The advantage of 1707 selecting observations independent of measurement data is that 1708 observations can be selected based on how readily available the data 1709 is for both LIS and Device. The amount and quality of the data can 1710 be selected based on the degree of assurance that is desired. 1712 Use of supporting observations is similar to both measurement 1713 validation and location validation. All three methods rely on 1714 independent validation of one or more properties. Applicability of 1715 each method is similar. 1717 Use of supporting observations can be used to limit or prevent all of 1718 the attacks identified in this document. 1720 7.2.3.2. Limitations 1722 The effectiveness of the validation method depends on the quality of 1723 the supporting observation: how hard it is to obtain at a different 1724 time or place, how difficult it is to guess and what other costs 1725 might be involved in acquiring this data. 1727 In the example of an observed radio signal, requesting a sample of 1728 the signal only provides an assurance that the Device is able to 1729 receive the signal transmitted by the measured radio transmitter. 1730 This only provides some assurance that the Device is within range of 1731 the transmitter. 1733 As with location validation, a Device might still be able to provide 1734 falsified measurements that could alter the value of the location 1735 information as long as the result is within this region. 1737 Requesting additional supporting observations can reduce the size of 1738 the region over which location information can be altered by an 1739 attacker, or increase trust in the result, but each additional has a 1740 cost. Supporting observations contribute little or nothing toward 1741 the primary goal of determining the location of the Device. Any 1742 costs in acquiring supporting observations are balanced against the 1743 degree of integrity desired of the resulting location information. 1745 7.2.4. Attribution 1747 Lying by proxy (Section 7.1.3) relies on the location recipient being 1748 able to attribute location information to a LIS. The effectiveness 1749 of this attack is negated if location information is explicitly 1750 attributed to a particular source. 1752 This requires an extension to the location object that explicitly 1753 identifies the source (or sources) of each item of location 1754 information. 1756 Rather than relying on a process that seeks to ensure that location 1757 information is accurate, this approach instead provides a location 1758 recipient with the information necessary to reach their own 1759 conclusion about the trustworthiness of the location information. 1761 Including an authenticated identity for all sources of measurement 1762 data is presents a number of technical and operational challenges. 1763 It is possible that the LIS has a transient relationship with a 1764 Device. A Device is not expected to share authentication information 1765 with a LIS. There is no assurance that Device identification is 1766 usable by a potential location recipient. Privacy concerns might 1767 also prevent the sharing identification information, even if it were 1768 available and usable. 1770 Identifying the type of measurement source allows a location 1771 recipient to make a decision about the trustworthiness of location 1772 information without depending on having authenticated identity 1773 information for each source. An element for this purpose is defined 1774 in Section 4.4. 1776 When including location information that is based on measurement data 1777 from sources that might be untrusted, a LIS SHOULD include 1778 alternative location information that is derived from trusted sources 1779 of measurement data. Each item of location information can then be 1780 labelled with the source of that data. 1782 A location recipient that is able to identify a specific source of 1783 measurement data (whether it be LIS or Device) can use this 1784 information to attribute location information to either or both 1785 entity. The location recipient is then better able to make decisions 1786 about trustworthiness based on the source of the data. 1788 A location recipient that does not understand the "source" element is 1789 unable to make this distinction. When constructing a PIDF-LO 1790 document, trusted location information MUST be placed in the PIDF-LO 1791 so that it is given higher priority to any untrusted location 1792 information according to Rule #8 of [RFC5491]. 1794 Attribution of information does nothing to address attacks that alter 1795 the observed parameters that are used in location determination 1796 (Section 7.1.5). 1798 7.2.5. Stateful Correlation of Location Requests 1800 Stateful examination of requests can be used to prevent a Device from 1801 attempting to map network topology using requests for location 1802 information (Section 7.1.2). 1804 Simply limiting the rate of requests from a single Device reduces the 1805 amount of data that a Device can acquire about network topology. 1807 8. Measurement Schemas 1809 The schema are broken up into their respective functions. There is a 1810 base container schema into which all measurements are placed, plus 1811 definitions for a measurement request (Section 8.1). A PIDF-LO 1812 extension is defined in a separate schema (Section 8.2). There is a 1813 basic types schema, that contains various base type definitions for 1814 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and 1815 MAC addresses (Section 8.3). Then each of the specific measurement 1816 types is defined in its own schema. 1818 8.1. Measurement Container Schema 1820 1821 1829 1830 1832 1833 1834 1836 This schema defines a framework for location measurements. 1837 1838 1840 1842 1843 1844 1845 1846 1847 1849 1850 1851 1852 1853 1854 1855 1856 1857 1859 1861 1862 1863 1864 1865 1867 1869 1870 1871 1872 1874 1875 1876 1877 1878 1879 1881 1882 1883 1884 1885 1886 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1903 Measurement Container Schema 1905 8.2. Measurement Source Schema 1907 1908 1915 1916 1918 1919 1920 1922 This schema defines an extension to PIDF-LO that indicates the 1923 type of source that produced the measurement data used in 1924 generating the associated location information. 1925 1926 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1942 Measurement Source PIDF-LO Extension Schema 1944 8.3. Base Type Schema 1946 Note that the pattern rules in the following schema wrap due to 1947 length constraints. None of the patterns contain whitespace. 1949 1950 1957 1958 1960 1961 1962 1964 This schema defines a set of base type elements. 1965 1966 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2008 2009 2010 2012 2013 2014 2015 2016 An IP version 6 address, based on RFC 4291. 2017 2018 2019 2020 2021 2022 2023 2024 2025 2027 2029 2031 2033 2035 2037 2038 2039 2040 2048 2049 2050 2051 2053 2054 2055 2056 2060 2061 2063 2064 2065 2066 2068 2069 2071 2073 Base Type Schema 2075 8.4. LLDP Measurement Schema 2077 2078 2086 2087 2089 2090 2091 2093 This schema defines a set of LLDP location measurements. 2094 2095 2096 2098 2099 2100 2101 2102 2103 2104 2105 2107 2108 2109 2110 2111 2113 2114 2115 2116 2118 2119 2120 2122 2123 2124 2125 2126 2127 2129 2131 LLDP measurement schema 2133 8.5. DHCP Measurement Schema 2135 2136 2144 2145 2147 2148 2149 2151 This schema defines a set of DHCP location measurements. 2152 2153 2155 2157 2158 2159 2160 2161 2162 2163 2164 2166 2168 2170 2172 2173 2174 2175 2176 2178 2179 2180 2181 2183 2184 2185 2187 2189 DHCP measurement schema 2191 8.6. WiFi Measurement Schema 2192 2193 2202 2203 2205 802.11 location measurements 2206 2207 2208 2210 This schema defines a basic set of 802.11 location measurements. 2211 2212 2214 2215 2217 2219 2220 2221 2222 2223 2225 2227 2228 2229 2230 2231 2233 2234 2235 2236 2237 2238 2241 2243 2245 2247 2249 2251 2253 2255 2257 2259 2261 2262 2264 2265 2266 2267 2269 2270 2271 2272 2273 2275 2276 2277 2278 2280 2281 2282 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2303 2304 2305 2306 2307 2309 2310 2311 2312 2313 2315 2316 2318 2320 2322 2323 2324 2325 2327 2328 2329 2330 2331 2332 2333 2335 2336 2337 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2354 2356 WiFi measurement schema 2358 8.7. Cellular Measurement Schema 2360 2361 2368 2369 2371 2372 2373 2375 This schema defines a set of cellular location measurements. 2376 2377 2379 2381 2382 2383 2384 2385 2386 2387 2388 2389 2391 2392 2393 2394 2395 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2416 2417 2418 2419 2420 2421 2423 2424 2426 2427 2428 2429 2431 2432 2433 2434 2435 2437 2438 2439 2440 2441 2443 2444 2445 2446 2447 2449 2451 2452 2453 2454 2455 2456 2457 2458 2459 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2476 2478 Cellular measurement schema 2480 8.8. GNSS Measurement Schema 2481 2482 2490 2491 2493 2494 2495 2497 This schema defines a set of GNSS location measurements 2498 2499 2501 2503 2504 2505 2506 2507 2508 2509 2511 2512 2513 2514 2515 2517 2519 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2537 2539 2540 2541 2543 2544 2545 2547 2548 2549 2550 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2565 GNSS measurement Schema 2567 8.9. DSL Measurement Schema 2569 2570 2578 2579 2581 DSL measurement definitions 2582 2583 2584 2586 This schema defines a basic set of DSL location measurements. 2587 2588 2590 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2625 2626 2627 2628 2629 2630 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2649 2651 DSL measurement schema 2653 9. IANA Considerations 2655 This section creates a registry for GNSS types (Section 5.5) and 2656 registers the namespaces and schema defined in Section 8. 2658 9.1. IANA Registry for GNSS Types 2660 This document establishes a new IANA registry for Global Navigation 2661 Satellite System (GNSS) types. The registry includes tokens for the 2662 GNSS type and for each of the signals within that type. Referring to 2663 [RFC5226], this registry operates under "Specification Required" 2664 rules. The IESG will appoint an Expert Reviewer who will advise IANA 2665 promptly on each request for a new or updated GNSS type. 2667 Each entry in the registry requires the following information: 2669 GNSS name: the name and a brief description of the GNSS 2671 Brief description: the name and a brief description of the GNSS 2673 GNSS token: a token that can be used to identify the GNSS 2675 Signals: a set of tokens that represent each of the signals that the 2676 system provides 2678 Documentation reference: a reference to one or more stable, public 2679 specifications that outline usage of the GNSS, including (but not 2680 limited to) signal specifications and time systems 2682 The registry initially includes two registrations: 2684 GNSS name: Global Positioning System (GPS) 2686 Brief description: a system of satellites that use spread-spectrum 2687 transmission, operated by the US military for commercial and 2688 military applications 2690 GNSS token: gps 2692 Signals: L1, L2, L1C, L2C, L5 2694 Documentation reference: Navstar GPS Space Segment/Navigation User 2695 Interface [GPS.ICD] 2697 GNSS name: Galileo 2699 Brief description: a system of satellites that operate in the same 2700 spectrum as GPS, operated by the European Union for commercial 2701 applications 2703 GNSS Token: galileo 2705 Signals: L1, E5A, E5B, E5A+B, E6 2707 Documentation Reference: Galileo Open Service Signal In Space 2708 Interface Control Document (SIS ICD) [Galileo.ICD] 2710 9.2. URN Sub-Namespace Registration for 2711 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2713 This section registers a new XML namespace, 2714 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines 2715 in [RFC3688]. 2717 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2719 Registrant Contact: IETF, GEOPRIV working group, 2720 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2722 XML: 2724 BEGIN 2725 2726 2728 2729 2730 Measurement Source for PIDF-LO 2731 2732 2733

Namespace for Location Measurement Source

2734

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

2735 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2736 with the RFC number for this specification.]] 2737

See RFCXXXX.

2738 2739 2740 END 2742 9.3. URN Sub-Namespace Registration for 2743 urn:ietf:params:xml:ns:geopriv:lm 2745 This section registers a new XML namespace, 2746 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 2747 [RFC3688]. 2749 URI: urn:ietf:params:xml:ns:geopriv:lm 2751 Registrant Contact: IETF, GEOPRIV working group, 2752 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2754 XML: 2756 BEGIN 2757 2758 2760 2761 2762 Measurement Container 2763 2764 2765

Namespace for Location Measurement Container

2766

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

2767 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2768 with the RFC number for this specification.]] 2769

See RFCXXXX.

2770 2771 2772 END 2774 9.4. URN Sub-Namespace Registration for 2775 urn:ietf:params:xml:ns:geopriv:lm:basetypes 2777 This section registers a new XML namespace, 2778 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 2779 in [RFC3688]. 2781 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 2783 Registrant Contact: IETF, GEOPRIV working group, 2784 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2786 XML: 2788 BEGIN 2789 2790 2792 2793 2794 Base Device Types 2795 2796 2797

Namespace for Base Types

2798

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

2799 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2800 with the RFC number for this specification.]] 2801

See RFCXXXX.

2802 2803 2805 END 2807 9.5. URN Sub-Namespace Registration for 2808 urn:ietf:params:xml:ns:geopriv:lm:lldp 2810 This section registers a new XML namespace, 2811 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 2812 [RFC3688]. 2814 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 2816 Registrant Contact: IETF, GEOPRIV working group, 2817 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2819 XML: 2821 BEGIN 2822 2823 2825 2826 2827 LLDP Measurement Set 2828 2829 2830

Namespace for LLDP Measurement Set

2831

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

2832 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2833 with the RFC number for this specification.]] 2834

See RFCXXXX.

2835 2836 2837 END 2839 9.6. URN Sub-Namespace Registration for 2840 urn:ietf:params:xml:ns:geopriv:lm:dhcp 2842 This section registers a new XML namespace, 2843 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 2844 [RFC3688]. 2846 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 2848 Registrant Contact: IETF, GEOPRIV working group, 2849 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2851 XML: 2853 BEGIN 2854 2855 2857 2858 2859 DHCP Measurement Set 2860 2861 2862

Namespace for DHCP Measurement Set

2863

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

2864 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2865 with the RFC number for this specification.]] 2866

See RFCXXXX.

2867 2868 2869 END 2871 9.7. URN Sub-Namespace Registration for 2872 urn:ietf:params:xml:ns:geopriv:lm:wifi 2874 This section registers a new XML namespace, 2875 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 2876 [RFC3688]. 2878 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 2880 Registrant Contact: IETF, GEOPRIV working group, 2881 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2883 XML: 2885 BEGIN 2886 2887 2889 2890 2891 WiFi Measurement Set 2892 2893 2894

Namespace for WiFi Measurement Set

2895

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

2896 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2897 with the RFC number for this specification.]] 2898

See RFCXXXX.

2899 2900 2902 END 2904 9.8. URN Sub-Namespace Registration for 2905 urn:ietf:params:xml:ns:geopriv:lm:cell 2907 This section registers a new XML namespace, 2908 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 2909 [RFC3688]. 2911 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 2913 Registrant Contact: IETF, GEOPRIV working group, 2914 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2916 XML: 2918 BEGIN 2919 2920 2922 2923 2924 Cellular Measurement Set 2925 2926 2927

Namespace for Cellular Measurement Set

2928

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

2929 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2930 with the RFC number for this specification.]] 2931

See RFCXXXX.

2932 2933 2934 END 2936 9.9. URN Sub-Namespace Registration for 2937 urn:ietf:params:xml:ns:geopriv:lm:gnss 2939 This section registers a new XML namespace, 2940 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 2941 [RFC3688]. 2943 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 2945 Registrant Contact: IETF, GEOPRIV working group, 2946 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2948 XML: 2950 BEGIN 2951 2952 2954 2955 2956 GNSS Measurement Set 2957 2958 2959

Namespace for GNSS Measurement Set

2960

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

2961 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2962 with the RFC number for this specification.]] 2963

See RFCXXXX.

2964 2965 2966 END 2968 9.10. URN Sub-Namespace Registration for 2969 urn:ietf:params:xml:ns:geopriv:lm:dsl 2971 This section registers a new XML namespace, 2972 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 2973 [RFC3688]. 2975 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 2977 Registrant Contact: IETF, GEOPRIV working group, 2978 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2980 XML: 2982 BEGIN 2983 2984 2986 2987 2988 DSL Measurement Set 2989 2990 2991

Namespace for DSL Measurement Set

2992

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

2993 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2994 with the RFC number for this specification.]] 2995

See RFCXXXX.

2996 2997 2999 END 3001 9.11. XML Schema Registration for Measurement Source Schema 3003 This section registers an XML schema as per the guidelines in 3004 [RFC3688]. 3006 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc 3008 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3009 Martin Thomson (martin.thomson@andrew.com). 3011 Schema: The XML for this schema can be found in Section 8.2 of this 3012 document. 3014 9.12. XML Schema Registration for Measurement Container Schema 3016 This section registers an XML schema as per the guidelines in 3017 [RFC3688]. 3019 URI: urn:ietf:params:xml:schema:lm 3021 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3022 Martin Thomson (martin.thomson@andrew.com). 3024 Schema: The XML for this schema can be found in Section 8.1 of this 3025 document. 3027 9.13. XML Schema Registration for Base Types Schema 3029 This section registers an XML schema as per the guidelines in 3030 [RFC3688]. 3032 URI: urn:ietf:params:xml:schema:lm:basetypes 3034 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3035 Martin Thomson (martin.thomson@andrew.com). 3037 Schema: The XML for this schema can be found in Section 8.3 of this 3038 document. 3040 9.14. XML Schema Registration for LLDP Schema 3042 This section registers an XML schema as per the guidelines in 3043 [RFC3688]. 3045 URI: urn:ietf:params:xml:schema:lm:lldp 3047 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3048 Martin Thomson (martin.thomson@andrew.com). 3050 Schema: The XML for this schema can be found in Section 8.4 of this 3051 document. 3053 9.15. XML Schema Registration for DHCP Schema 3055 This section registers an XML schema as per the guidelines in 3056 [RFC3688]. 3058 URI: urn:ietf:params:xml:schema:lm:dhcp 3060 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3061 Martin Thomson (martin.thomson@andrew.com). 3063 Schema: The XML for this schema can be found in Section 8.5 of this 3064 document. 3066 9.16. XML Schema Registration for WiFi Schema 3068 This section registers an XML schema as per the guidelines in 3069 [RFC3688]. 3071 URI: urn:ietf:params:xml:schema:lm:wifi 3073 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3074 Martin Thomson (martin.thomson@andrew.com). 3076 Schema: The XML for this schema can be found in Section 8.6 of this 3077 document. 3079 9.17. XML Schema Registration for Cellular Schema 3081 This section registers an XML schema as per the guidelines in 3082 [RFC3688]. 3084 URI: urn:ietf:params:xml:schema:lm:cellular 3086 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3087 Martin Thomson (martin.thomson@andrew.com). 3089 Schema: The XML for this schema can be found in Section 8.7 of this 3090 document. 3092 9.18. XML Schema Registration for GNSS Schema 3094 This section registers an XML schema as per the guidelines in 3095 [RFC3688]. 3097 URI: urn:ietf:params:xml:schema:lm:gnss 3099 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3100 Martin Thomson (martin.thomson@andrew.com). 3102 Schema: The XML for this schema can be found in Section 8.8 of this 3103 document. 3105 9.19. XML Schema Registration for DSL Schema 3107 This section registers an XML schema as per the guidelines in 3108 [RFC3688]. 3110 URI: urn:ietf:params:xml:schema:lm:dsl 3112 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3113 Martin Thomson (martin.thomson@andrew.com). 3115 Schema: The XML for this schema can be found in Section 8.9 of this 3116 document. 3118 10. Acknowledgements 3120 Thanks go to Simon Cox for his comments relating to terminology that 3121 have helped ensure that this document is aligns with ongoing work in 3122 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 3123 review and comments on the GNSS sections of this document. Thanks to 3124 Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for their 3125 significant input to and suggestions for improving the 802.11 3126 measurements. Thanks to Cullen Jennings for feedback and 3127 suggestions. Bernard Aboba provided review and feedback on a range 3128 of measurement data definitions. Mary Barnes provided a review and 3129 corrections. 3131 11. References 3133 11.1. Normative References 3135 [DSL.TR025] 3136 Wang, R., "Core Network Architecture Recommendations for 3137 Access to Legacy Data Networks over ADSL", September 1999. 3139 [DSL.TR101] 3140 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 3141 Aggregation", April 2006. 3143 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", 3144 ICD GPS-200, Apr 2000. 3146 [Galileo.ICD] 3147 GJU, "Galileo Open Service Signal In Space Interface 3148 Control Document (SIS ICD)", May 2006. 3150 [I-D.ietf-geopriv-http-location-delivery] 3151 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 3152 "HTTP Enabled Location Delivery (HELD)", 3153 draft-ietf-geopriv-http-location-delivery-16 (work in 3154 progress), August 2009. 3156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3157 Requirement Levels", BCP 14, RFC 2119, March 1997. 3159 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3160 Format", RFC 4119, December 2005. 3162 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3163 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3164 May 2008. 3166 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3167 Presence Information Data Format Location Object (PIDF-LO) 3168 Usage Clarification, Considerations, and Recommendations", 3169 RFC 5491, March 2009. 3171 11.2. Informative References 3173 [ANSI/TIA-1057] 3174 ANSI/TIA, "Link Layer Discovery Protocol for Media 3175 Endpoint Devices", TIA 1057, April 2006. 3177 [GPS.SPOOF] 3178 Scott, L., "Anti-Spoofing and Authenticated Signal 3179 Architectures for Civil Navigation Signals", ION- 3180 GNSS Portland, Oregon, 2003. 3182 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side 3183 spoofing and detection for Assisted-GPS", Proceedings of 3184 International Global Navigation Satellite Systems Society 3185 (IGNSS) Symposium 2009 16, December 2009, 3186 . 3188 [I-D.ietf-geopriv-held-identity-extensions] 3189 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 3190 Barnes, "Use of Device Identity in HTTP-Enabled Location 3191 Delivery (HELD)", 3192 draft-ietf-geopriv-held-identity-extensions-04 (work in 3193 progress), June 2010. 3195 [I-D.thomson-geopriv-uncertainty] 3196 Thomson, M. and J. Winterbottom, "Representation of 3197 Uncertainty and Confidence in PIDF-LO", 3198 draft-thomson-geopriv-uncertainty-05 (work in progress), 3199 May 2010. 3201 [IANA.enterprise] 3202 IANA, "Private Enterprise Numbers", 3203 . 3205 [IEEE.80211] 3206 IEEE, "Wireless LAN Medium Access Control (MAC) and 3207 Physical Layer (PHY) specifications - IEEE 802.11 Wireless 3208 Network Management", IEEE Std 802.11-2007, June 2007. 3210 [IEEE.80211V] 3211 IEEE, "Wireless LAN Medium Access Control (MAC) and 3212 Physical Layer (PHY) specifications - IEEE 802.11 Wireless 3213 Network Management (Draft)", P802.11v D12.0, June 2010. 3215 [IEEE.8021AB] 3216 IEEE, "IEEE Standard for Local and Metropolitan area 3217 networks, Station and Media Access Control Connectivity 3218 Discovery", 802.1AB, June 2005. 3220 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3221 "Remote Authentication Dial In User Service (RADIUS)", 3222 RFC 2865, June 2000. 3224 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 3225 RFC 3046, January 2001. 3227 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3228 January 2004. 3230 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 3231 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 3233 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 3234 Suboption for the Dynamic Host Configuration Protocol 3235 (DHCP) Relay Agent Option", RFC 3993, March 2005. 3237 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3238 Architecture", RFC 4291, February 2006. 3240 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3241 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 3242 June 2006. 3244 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3245 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 3246 August 2006. 3248 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 3249 Mechanism", RFC 5808, May 2010. 3251 Authors' Addresses 3253 Martin Thomson 3254 Andrew 3255 Andrew Building (39) 3256 University of Wollongong 3257 Northfields Avenue 3258 Wollongong, NSW 2522 3259 AU 3261 Phone: +61 2 4221 2915 3262 Email: martin.thomson@andrew.com 3263 URI: http://www.andrew.com/ 3265 James Winterbottom 3266 Andrew 3267 Andrew Building (39) 3268 University of Wollongong 3269 Northfields Avenue 3270 NSW 2522 3271 AU 3273 Phone: +61 2 4221 2938 3274 Email: james.winterbottom@andrew.com 3275 URI: http://www.andrew.com/