idnits 2.17.1 draft-ietf-geopriv-held-measurements-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 06, 2013) is 3878 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 2160, but not defined == Missing Reference: '0-4' is mentioned on line 2160, but not defined == Missing Reference: '0-9' is mentioned on line 2160, but not defined == Missing Reference: '0-1' is mentioned on line 2160, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.80211' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.8021AB' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Winterbottom 5 Expires: March 10, 2014 Unaffiliated 6 September 06, 2013 8 Using Device-provided Location-Related Measurements in Location 9 Configuration Protocols 10 draft-ietf-geopriv-held-measurements-09 12 Abstract 14 This document describes a protocol for a Device to provide location- 15 related measurement data to a Location Information Server (LIS) 16 within a request for location information. Location-related 17 measurement information are observations concerning properties 18 related to the position of a Device, which could be data about 19 network attachment or about the physical environment. A LIS is able 20 to use the location-related measurement data to improve the accuracy 21 of the location estimate it provides to the Device. A basic set of 22 location-related measurements are defined, including common modes of 23 network attachment as well as assisted Global Navigation Satellite 24 System (GNSS) parameters. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 10, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions used in this document . . . . . . . . . . . . . . 5 62 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 5 63 4. Location-Related Measurement Data Types . . . . . . . . . . . 7 64 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 7 65 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 8 66 4.1.2. Expiry Time on Location-Related Measurement Data . . 8 67 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 8 68 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . 9 69 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 10 70 4.4. Identifying Location Provenance . . . . . . . . . . . . . 11 71 5. Location-Related Measurement Data Types . . . . . . . . . . . 13 72 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14 73 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15 74 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . 15 75 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 19 76 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 19 77 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 22 78 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 22 79 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . 24 80 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . 24 81 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . 24 82 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25 83 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . 25 84 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26 85 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26 86 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . 27 87 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . 28 88 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 89 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . 28 90 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . 29 91 6.3. Measurement Data and Location URIs . . . . . . . . . . . 29 92 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 30 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 94 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 30 95 7.1.1. Acquiring Location Information Without Authorization 31 96 7.1.2. Extracting Network Topology Data . . . . . . . . . . 32 97 7.1.3. Exposing Network Topology Data . . . . . . . . . . . 32 98 7.1.4. Lying By Proxy . . . . . . . . . . . . . . . . . . . 32 99 7.1.5. Measurement Replay . . . . . . . . . . . . . . . . . 33 100 7.1.6. Environment Spoofing . . . . . . . . . . . . . . . . 34 101 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 35 102 7.2.1. Measurement Validation . . . . . . . . . . . . . . . 36 103 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 36 104 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37 105 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38 106 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 38 107 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 38 108 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39 109 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 39 110 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40 111 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 40 112 7.2.5. Stateful Correlation of Location Requests . . . . . . 41 113 7.3. An Unauthorized or Compromised LIS . . . . . . . . . . . 42 114 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42 115 8.1. Measurement Container Schema . . . . . . . . . . . . . . 42 116 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 44 117 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . 45 118 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48 119 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49 120 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 50 121 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54 122 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 56 123 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . 58 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 125 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . 60 126 9.2. URN Sub-Namespace Registration for 127 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61 128 9.3. URN Sub-Namespace Registration for 129 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62 130 9.4. URN Sub-Namespace Registration for 131 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63 132 9.5. URN Sub-Namespace Registration for 133 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . 63 134 9.6. URN Sub-Namespace Registration for 135 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . 64 136 9.7. URN Sub-Namespace Registration for 137 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . 65 138 9.8. URN Sub-Namespace Registration for 139 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . 65 140 9.9. URN Sub-Namespace Registration for 141 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . 66 142 9.10. URN Sub-Namespace Registration for 143 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67 145 9.11. XML Schema Registration for Measurement Source Schema . . 67 146 9.12. XML Schema Registration for Measurement Container Schema 68 147 9.13. XML Schema Registration for Base Types Schema . . . . . . 68 148 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68 149 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 68 150 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69 151 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69 152 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 69 153 9.19. XML Schema Registration for DSL Schema . . . . . . . . . 69 154 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 155 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 156 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 157 11.2. Informative References . . . . . . . . . . . . . . . . . 72 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 160 1. Introduction 162 A Location Configuration Protocol (LCP) provides a means for a Device 163 to request information about its physical location from an access 164 network. A location information server (LIS) is the server that 165 provides location information that is available due to the knowledge 166 it has about the network and physical environment. 168 As a part of the access network, the LIS is able to acquire 169 measurement results related to Device location from network elements. 170 The LIS also has access to information about the network topology 171 that can be used to turn measurement data into location information. 172 This information can be further enhanced with information acquired 173 from the Device itself. 175 A Device is able to make observations about its network attachment, 176 or its physical environment. The location-related measurement data 177 might be unavailable to the LIS; alternatively, the LIS might be able 178 to acquire the data, but at a higher cost, in time or an other 179 metric. Providing measurement data gives the LIS more options in 180 determining location, which could improve the quality of the service 181 provided by the LIS. Improvements in accuracy are one potential 182 gain, but improved response times and lower error rates are possible. 184 This document describes a means for a Device to report location- 185 related measurement data to the LIS. Examples based on the HELD 186 [RFC5985] location configuration protocol are provided. 188 2. Conventions used in this document 190 The terms LIS and Device are used in this document in a manner 191 consistent with the usage in [RFC5985]. 193 This document also uses the following definitions: 195 Location Measurement: An observation about the physical properties 196 of a particular Device's position in time and space. The result 197 of a location measurement - "location-related measurement data", 198 or simply "measurement data" given sufficient context - can be 199 used to determine the location of a Device. Location-related 200 measurement data does not directly identify a Device, though it 201 could do indirectly. Measurement data can change with time if the 202 location of the Device also changes. 204 Location-related measurement data does not necessarily contain 205 location information directly, but it can be used in combination 206 with contextual knowledge and/or algorithms to derive location 207 information. Examples of location-related measurement data are: 208 radio signal strength or timing measurements, Ethernet switch and 209 port identifiers. 211 Location-related measurement data can be considered sighting 212 information, based on the definition in [RFC3693]. 214 Location Estimate: A location estimate is an approximation of where 215 the Device is located. Location estimates are derived from 216 location measurements. Location estimates are subject to 217 uncertainty, which arise from errors in measurement results. 219 GNSS: Global Navigation Satellite System. A satellite-based system 220 that provides positioning and time information. For example, the 221 US Global Positioning System (GPS) or the European Galileo system. 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 3. Location-Related Measurements in LCPs 229 This document defines a standard container for the conveyance of 230 location-related measurement parameters in location configuration 231 protocols. This is an XML container that identifies parameters by 232 type and allows the Device to provide the results of any measurement 233 it is able to perform. A set of measurement schemas are also defined 234 that can be carried in the generic container. 236 A simple example of measurement data conveyance is illustrated by the 237 example message in Figure 1. This shows a HELD location request 238 message with an Ethernet switch and port measurement taken using LLDP 239 [IEEE.8021AB]. 241 242 civic 243 245 246 0a01003c 247 c2 248 249 250 252 Figure 1: HELD Location Request with Measurement Data 254 This LIS can ignore measurement data that it does not support or 255 understand. The measurements defined in this document follow this 256 rule: extensions that could result in backward incompatibility MUST 257 be added as new measurement definitions rather than extensions to 258 existing types. 260 Multiple sets of measurement data, either of the same type or from 261 different sources, can be included in the "measurements" element. 262 See Section 4.1.1 for details on repetition of this element. 264 A LIS can choose to use or ignore location-related measurement data 265 in determining location, as long as rules regarding use and retention 266 (Section 6) are respected. The "method" parameter in the Presence 267 Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD 268 be adjusted to reflect the method used. A correct "method" can 269 assist location recipients in assessing the quality (both accuracy 270 and integrity) of location information, though there could be reasons 271 to withhold information about the source of data. 273 Measurement data is typically only used to serve the request that it 274 is included in. There may be exceptions, particularly with respect 275 to location URIs. Section 6 provides more information on usage 276 rules. 278 Location-related measurement data need not be provided exclusively by 279 Devices. A third party location requester (for example, see 280 [RFC6155]) can request location information using measurement data, 281 if the requester is able to acquire measurement data and authorized 282 to distribute it. There are specific privacy considerations relating 283 to the use of measurements by third parties, which are discussed in 284 Section 6.4. 286 Location-related measurement data and its use presents a number of 287 privacy and security challenges. These are described in more detail 288 in Section 6 and Section 7. 290 4. Location-Related Measurement Data Types 292 A common container is defined for the expression of location 293 measurement data, as well as a simple means of identifying specific 294 types of measurement data for the purposes of requesting them. 296 The following example shows a measurement container with measurement 297 time and expiration time included. A WiFi measurement is enclosed. 299 302 303 304 00-12-F0-A0-80-EF 305 wlan-home 306 307 308 310 Figure 2: Measurement Example 312 4.1. Measurement Container 314 The "measurements" element is used to encapsulate measurement data 315 that is collected at a certain point in time. It contains time-based 316 attributes that are common to all forms of measurement data, and 317 permits the inclusion of arbitrary measurement data. The elements 318 that are included within the "measurements" element are generically 319 referred to as "measurement elements". 321 This container can be added to a request for location information in 322 any protocol capable of carrying XML, such as a HELD location request 323 [RFC5985]. 325 4.1.1. Time of Measurement 327 The "time" attribute records the time that the measurement or 328 observation was made. This time can be different to the time that 329 the measurement information was reported. Time information can be 330 used to populate a timestamp on the location result, or to determine 331 if the measurement information is used. 333 The "time" attribute SHOULD be provided whenever possible. This 334 allows a LIS to avoid selecting an arbitrary timestamp. Exceptions 335 to this, where omitting time might make sense, include relatively 336 static types of measurement (for instance, the DSL measurements in 337 Section 5.6) or for legacy Devices that don't record time information 338 (such as the Home Location Register/Home Subscriber Server for 339 cellular). 341 The "time" attribute is attached to the root "measurement" element. 342 Multiple measurements can often be given the same timestamp, even 343 when the measurements were not actually taken at the same time 344 (consider a set of measurements taken sequentially, where the 345 difference in time between observations is not significant). 346 Measurements cannot be grouped if they have different types, or there 347 is a need for independent time values on each measurement. In these 348 instances, multiple measurement sets are necessary. 350 4.1.2. Expiry Time on Location-Related Measurement Data 352 A Device is able to indicate an expiry time in the location 353 measurement using the "expires" attribute. Nominally, this attribute 354 indicates how long information is expected to be valid, but it can 355 also indicate a time limit on the retention and use of the 356 measurement data. A Device can use this attribute to request that 357 the LIS not retain measurement data beyond the indicated time. 359 Note: Movement of the Device might result in the measurement data 360 being invalidated before the expiry time. 362 A Device is advised to set the "expires" attribute to earlier of: the 363 time that measurements are likely to be unusable, and the time that 364 it desires to have measurements discarded by the LIS. A Device that 365 does not desire measurement data to be retained can omit the 366 "expires" attribute. Section 6 describes more specific rules 367 regarding measurement data retention. 369 4.2. RMS Error and Number of Samples 370 Often a measurement is taken more than once. Reporting the average 371 of a number of measurement results mitigates the effects of random 372 errors that occur in the measurement process. 374 Reporting each measurement individually can be the most effective 375 method of reporting multiple measurements. This is achieved by 376 providing multiple measurement elements for different times. 378 The alternative is to aggregate multiple measurements and report a 379 mean value across the set of measurements. Additional information 380 about the distribution of the results can be useful in determining 381 location uncertainty. 383 Two attributes are provided for use on some measurement values: 385 rmsError: The root-mean-squared (RMS) error of the set of 386 measurement values used in calculating the result. RMS error is 387 expressed in the same units as the measurement, unless otherwise 388 stated. If an accurate value for RMS error is not known, this 389 value can be used to indicate an upper bound or estimate for the 390 RMS error. 392 samples: The number of samples that were taken in determining the 393 measurement value. If omitted, this value can be assumed to be 394 large enough that the RMS error is an indication of the standard 395 deviation of the sample set. 397 For some measurement techniques, measurement error is largely 398 dependent on the measurement technique employed. In these cases, 399 measurement error is largely a product of the measurement technique 400 and not the specific circumstances, so RMS error does not need to be 401 actively measured. A fixed value MAY be provided for RMS error where 402 appropriate. 404 The "rmsError" and "samples" elements are added as attributes of 405 specific measurement data types. 407 4.2.1. Time RMS Error 409 Measurement of time can be significant in certain circumstances. The 410 GNSS measurements included in this document are one such case where a 411 small error in time can result in a large error in location. Factors 412 such as clock drift and errors in time synchronization can result in 413 small, but significant, time errors. Including an indication of the 414 quality of time measurements can be helpful. 416 A "timeError" attribute MAY be added to the "measurement" element to 417 indicate the RMS error in time. "timeError" indicates an upper bound 418 on the time RMS error in seconds. 420 The "timeError" attribute does not apply where multiple samples of a 421 measurement are taken over time. If multiple samples are taken, each 422 SHOULD be included in a different "measurement" element. 424 4.3. Measurement Request 426 A measurement request is used by a protocol peer to describe a set of 427 measurement data that it desires. A "measurementRequest" element is 428 defined that can be included in a protocol exchange. 430 For instance, a LIS can use a measurement request in HELD responses. 431 If the LIS is unable to provide location information, but it believes 432 that a particular measurement type would enable it to provide a 433 location, it can include a measurement request in an error response. 435 The "measurement" element of the measurement request identifies the 436 type of measurement that is requested. The "type" attribute of this 437 element indicates the type of measurement, as identified by an XML 438 qualified name. An "samples" attribute MAY be used to indicate how 439 many samples of the identified measurement are requested. 441 The "measurement" element can be repeated to request multiple (or 442 alternative) measurement types. 444 Additional XML content might be defined for a particular measurement 445 type that is used to further refine a request. These elements either 446 constrain what is requested or specify non-mandatory components of 447 the measurement data that are needed. These are defined along with 448 the specific measurement type. 450 In the HELD protocol, the inclusion of a measurement request in an 451 error response with a code of "locationUnknown" indicates that 452 providing measurements would increase the likelihood of a subsequent 453 request being successful. 455 The following example shows a HELD error response that indicates that 456 WiFi measurement data would be useful if a later request were made. 457 Additional elements indicate that received signal strength for an 458 802.11n access point is requested. 460 462 Insufficient measurement data 463 466 467 n 468 wifi:rcpi 469 470 471 473 Figure 3: HELD Error Requesting Measurement Data 475 A measurement request that is included in other HELD messages has 476 undefined semantics and can be safely ignored. Other specifications 477 might define semantics for measurement requests under other 478 conditions. 480 4.4. Identifying Location Provenance 482 An extension is made to the PIDF-LO [RFC4119] that allows a location 483 recipient to identify the source (or sources) of location information 484 and the measurement data that was used to determine that location 485 information. 487 The "source" element is added to the "geopriv" element of the PIDF- 488 LO. This element does not identify specific entities. Instead, it 489 identifies the type of source. 491 The following types of measurement source are identified: 493 lis: Location information is based on measurement data that the LIS 494 or sources that it trusts have acquired. This label MAY be used 495 if measurement data provided by the Device has been completely 496 validated by the LIS. 498 device: A LIS MUST include this value if the location information is 499 based (in whole or part) on measurement data provided by the 500 Device and if the measurement data isn't completely validated. 502 other: Location information is based on measurement data that a 503 third party has provided. This might be an authorized third party 504 that uses identity parameters [RFC6155] or any other entity. The 505 LIS MUST include this, unless the third party is trusted by the 506 LIS to provide measurement data. 508 No assertion is made about the veracity of the measurement data from 509 sources other than the LIS. A combination of tags MAY be included to 510 indicate that measurement data from multiple types of sources was 511 used. 513 For example, the first tuple of the following PIDF-LO indicates that 514 measurement data from a LIS and a device was combined to produce the 515 result, the second tuple was produced by the LIS alone. 517 523 524 525 526 527 528 7.34324 134.47162 529 530 850.24 531 532 533 534 535 OTDOA 536 lis device 537 538 539 540 541 542 543 544 545 7.34379 134.46484 546 547 9000 548 549 550 551 552 Cell 553 lis 554 555 556 557 559 PIDF-LO document with source labels 561 5. Location-Related Measurement Data Types 563 This document defines location-related measurement data types for a 564 range of common network types. 566 All included measurement data definitions allow for arbitrary 567 extension in the corresponding schema. New parameters that are 568 applicable to location determination are added as new XML elements in 569 a unique namespace, not by adding elements to an existing namespace. 571 5.1. LLDP Measurements 573 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent 574 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet, 575 WiFi, 802.16). These messages all contain identification information 576 for the sending node, which can be used to determine location 577 information. A Device that receives LLDP messages can report this 578 information as a location-related measurement to the LIS, which is 579 then able to use the measurement data in determining the location of 580 the Device. 582 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery 583 (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location 584 information directly from an LLDP endpoint. Where this 585 information is available, it might be unnecessary to use any other 586 form of location configuration. 588 Values are provided as hexadecimal sequences. The Device MUST report 589 the values directly as they were provided by the adjacent node. 590 Attempting to adjust or translate the type of identifier is likely to 591 cause the measurement data to be useless. 593 Where a Device has received LLDP messages from multiple adjacent 594 nodes, it should provide information extracted from those messages by 595 repeating the "lldp" element. 597 An example of an LLDP measurement is shown in Figure 4. This shows 598 an adjacent node (chassis) that is identified by the IP address 599 192.0.2.45 (hexadecimal c000022d) and the port on that node is 600 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 602 604 605 c000022d 606 a2 607 608 610 Figure 4: LLDP Measurement Example 612 IEEE 802 Devices that are able to obtain information about adjacent 613 network switches and their attachment to them by other means MAY use 614 this data type to convey this information. 616 5.2. DHCP Relay Agent Information Measurements 618 The DHCP Relay Agent Information option [RFC3046] provides 619 measurement data about the network attachment of a Device. This 620 measurement data can be included in the "dhcp-rai" element. 622 The elements in the DHCP relay agent information options are opaque 623 data types assigned by the DHCP relay agent. The three items MAY be 624 omitted if unknown: circuit identifier ("circuit", circuit [RFC3046], 625 Interface-Id [RFC3315]), remote identifier ("remote", Remote ID 626 [RFC3046], or remote-id [RFC4649]) and subscriber identifier 627 ("subscriber", subscriber-id [RFC3993], Subscriber-ID [RFC4580]). 628 The DHCPv6 remote-id has an associated enterprise number 629 [IANA.enterprise] as an XML attribute. 631 633 634 192.0.2.158 635 108b 636 637 639 Figure 5: DHCP Relay Agent Information Measurement Example 641 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 642 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]; 643 IPv6 addresses SHOULD use the form described in [RFC5952]. The 644 enterprise number is specified as a decimal integer. All other 645 information is included verbatim from the DHCP request in hexadecimal 646 format. 648 The "subscriber" element could be considered sensitive. This 649 information MUST NOT be provided to a LIS that is not authorized to 650 receive information about the access network. See Section 7.1.3 for 651 more details. 653 5.3. 802.11 WLAN Measurements 655 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to 656 provide information about the access point (AP) that it is attached 657 to, or other WiFi points it is able to see. This is provided using 658 the "wifi" element, as shown in Figure 6, which shows a single 659 complete measurement for a single access point. 661 663 664 Intel(r)PRO/Wireless 2200BG 665 666 AB-CD-EF-AB-CD-EF 667 example 668 5 669 670 671 -34.4 150.8 672 673 674 a 675 5 676 2 677 2 678 2.56e-9 679 680 23 681 5 682 -59 683 23 684 685 686 10 687 9 688 -98.5 689 7.5 690 691 692 693 695 Figure 6: 802.11 WLAN Measurement Example 697 A wifi element is made up of one or more access points, and a 698 "nicType" element, which MAY be omitted. Each access point is 699 described using the "ap" element, which is comprised of the following 700 fields: 702 bssid: The basic service set identifier. In an Infrastructure BSS 703 network, the bssid is the 48 bit MAC address of the access point. 705 The "verified" attribute of this element describes whether the 706 device has verified the MAC address or it authenticated the access 707 point or the network operating the access point (for example, a 708 captive portal accessed through the access point has been 709 authenticated). This attributes defaults to a value of "false" 710 when omitted. 712 ssid: The service set identifier (SSID) for the wireless network 713 served by the access point. 715 The SSID is a 32-octet identifier that is commonly represented as 716 a ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent 717 octets that cannot be directly included in an XML element, 718 escaping is used. Sequences of octets that do not represent a 719 valid UTF-8 encoding can be escaped using a backslash ('\') 720 followed by two case-insensitive hexadecimal digits representing 721 the value of a single octet. 723 The canonical or value-space form of an SSID is a sequence of up 724 to 32 octets that is produced from the concatenation of UTF-8 725 encoded sequences of unescaped characters and octets derived from 726 escaped components. 728 channel: The channel number (frequency) that the access point 729 operates on. 731 location: The location of the access point, as reported by the 732 access point. This element contains any valid location, using the 733 rules for a "location-info" element, as described in [RFC5491]. 735 type: The network type for the network access. This element 736 includes the alphabetic suffix of the 802.11 specification that 737 introduced the radio interface, or PHY; e.g. "a", "b", "g", or 738 "n". 740 band: The frequency band for the radio, in gigahertz (GHz). 802.11 741 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5 742 gigahertz frequency bands. 744 regclass: The operating class (regulatory domain and class in older 745 versions in 802.11), see Annex E of [IEEE.80211]. The "country" 746 attribute optionally includes the applicable two character country 747 identifier (dot11CountryString), which can be followed by an 'O', 748 'I' or 'X'. The element text content includes the value of the 749 regulatory class: an 8-bit integer in decimal form. 751 antenna: The antenna identifier for the antenna that the access 752 point is using to transmit the measured signals. 754 flightTime: Flight time is the difference between the time of 755 departure (TOD) of signal from a transmitting station and time of 756 arrival (TOA) of signal at a receiving station, as defined in 758 [IEEE.80211]. Measurement of this value requires that stations 759 synchronize their clocks. This value can be measured by access 760 point or Device; because the flight time is assumed to be the same 761 in either direction - aside from measurement errors - only a 762 single element is provided. This element permits the use of the 763 "rmsError" and "samples" attributes. RMS error might be derived 764 from the reported RMS error in TOD and TOA. 766 apSignal: Measurement information for the signal transmitted by the 767 access point, as observed by the Device. Some of these values are 768 derived from 802.11v [IEEE.80211] messages exchanged between 769 Device and access point. The contents of this element include: 771 transmit: The transmit power reported by the access point, in 772 dBm. 774 gain: The gain of the access point antenna reported by the access 775 point, in dB. 777 rcpi: The received channel power indicator for the access point 778 signal, as measured by the Device. This value SHOULD be in 779 units of dBm (with RMS error in dB). If power is measured 780 in a different fashion, the "dBm" attribute MUST be set to 781 "false". Signal strength reporting on current hardware uses 782 a range of different mechanisms; therefore, the value of the 783 "nicType" element SHOULD be included if the units are not 784 known to be in dBm and the value reported by the hardware 785 should be included without modification. This element 786 permits the use of the "rmsError" and "samples" attributes. 788 rsni: The received signal to noise indicator in dB. This element 789 permits the use of the "rmsError" and "samples" attributes. 791 deviceSignal: Measurement information for the signal transmitted by 792 the device, as reported by the access point. This element 793 contains the same child elements as the "ap" element, with the 794 access point and Device roles reversed. 796 The only mandatory element in this structure is "bssid". 798 The "nicType" element is used to specify the make and model of the 799 wireless network interface in the Device. Different 802.11 chipsets 800 report measurements in different ways, so knowing the network 801 interface type aids the LIS in determining how to use the provided 802 measurement data. The content of this field is unconstrained and no 803 mechanisms are specified to ensure uniqueness. This field is 804 unlikely to be useful, except under tightly controlled circumstances. 806 5.3.1. Wifi Measurement Requests 808 Two elements are defined for requesting WiFi measurements in a 809 measurement request: 811 type: The "type" element identifies the desired type (or types that 812 are requested). 814 parameter: The "parameter" element identifies measurements that are 815 requested for each measured access point. An element is 816 identified by its qualified name. The "context" parameter can be 817 used to specify if an element is included as a child of the "ap" 818 or "device" elements; omission indicates that it applies to both. 820 Multiple types or parameters can be requested by repeating either 821 element. 823 5.4. Cellular Measurements 825 Cellular Devices are common throughout the world and base station 826 identifiers can provide a good source of coarse location information. 827 Cellular measurements can be provided to a LIS run by the cellular 828 operator, or may be provided to an alternative LIS operator that has 829 access to one of several global cell-id to location mapping 830 databases. 832 A number of advanced location determination methods have been 833 developed for cellular networks. For these methods a range of 834 measurement parameters can be collected by the network, Device, or 835 both in cooperation. This document includes a basic identifier for 836 the wireless transmitter only; future efforts might define additional 837 parameters that enable more accurate methods of location 838 determination. 840 The cellular measurement set allows a Device to report to a LIS any 841 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10) 842 cells that it is able to observe. Cells are reported using their 843 global identifiers. All 3GPP cells are identified by public land 844 mobile network (PLMN), which is formed of mobile country code (MCC) 845 and mobile network code (MNC); specific fields are added for each 846 network type. 848 Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. 849 Bit-level formats for CDMA cell identifiers are described in 850 [TIA-2000.5]; decimal representations are used. 852 MCC and MNC are provided as decimal digit sequences; a leading zero 853 in an MCC or MNC is significant. All other values are decimal 854 integers. 856 858 859 860 4652080936424 861 862 863 4650610736789 864 865 866 868 Long term evolution (LTE) cells are identified by a 28-bit cell 869 identifier (eucid). 871 Figure 7: Example LTE Cellular Measurement 873 875 876 877 46520 878 200065000 879 880 881 46506 882 1638332767 883 884 885 887 Universal mobile telephony service (UMTS) cells are identified by 12- 888 or 16-bit radio network controller (rnc) id and a 16-bit cell id 889 (cid). 891 Figure 8: Example UMTS Cellular Measurement 893 895 896 897 46506 898 1638332767 899 901 902 904 Global System for Mobile communication (GSM) cells are identified by 905 a 16-bit location area code (lac) and 16-bit cell id (cid). 907 Figure 9: Example GSM Cellular Measurement 909 911 912 913 15892472312 914 915 916 15892472313 917 918 919 921 Code division multiple access (CDMA) cells are not identified by 922 PLMN, instead these use a 15-bit system id (sid), a 16-bit network id 923 (nid) and a 16-bit base station id (baseid). 925 Figure 10: Example CDMA Cellular Measurement 927 In general, a cellular Device will be attached to the cellular 928 network and so the notion of a serving cell exists. Cellular network 929 also provide overlap between neighbouring sites, so a mobile Device 930 can hear more than one cell. The measurement schema supports sending 931 both the serving cell and any other cells that the mobile might be 932 able to hear. In some cases, the Device could simply be listening to 933 cell information without actually attaching to the network, mobiles 934 without a SIM are an example of this. In this case the Device could 935 report cells it can hear without identifying any particular cell as 936 serving cell. An example of this is shown in Figure 11. 938 940 941 942 46520 943 200065000 944 945 946 46506 947 1638332767 948 950 951 953 Figure 11: Example Observed Cellular Measurement 955 5.4.1. Cellular Measurement Requests 957 Two elements can be used in measurement requests for cellular 958 measurements: 960 type: A label indicating the type of identifier to provide: one of 961 "gsm", "umts", "lte", or "cdma". 963 network: The network portion of the cell identifier. For 3GPP 964 networks, this is the combination of MCC and MNC; for CDMA, this 965 is the network identifier. 967 Multiple identifier types or networks can be identified by repeating 968 either element. 970 5.5. GNSS Measurements 972 A Global Navigation Satellite System (GNSS) uses orbiting satellites 973 to transmit signals. A Device with a GNSS receiver is able to take 974 measurements from the satellite signals. The results of these 975 measurements can be used to determine time and the location of the 976 Device. 978 Determining location and time in autonomous GNSS receivers follows 979 three steps: 981 Signal acquisition: During the signal acquisition stage, the 982 receiver searches for the repeating code that is sent by each GNSS 983 satellite. Successful operation typically requires measurement 984 data for a minimum of 5 satellites. At this stage, measurement 985 data is available to the Device. 987 Navigation message decode: Once the signal has been acquired, the 988 receiver then receives information about the configuration of the 989 satellite constellation. This information is broadcast by each 990 satellite and is modulated with the base signal at a low rate; for 991 instance, GPS sends this information at about 50 bits per second. 993 Calculation: The measurement data is combined with the data on the 994 satellite constellation to determine the location of the receiver 995 and the current time. 997 A Device that uses a GNSS receiver is able to report measurements 998 after the first stage of this process. A LIS can use the results of 999 these measurements to determine a location. In the case where there 1000 are fewer results available than the optimal minimum, the LIS might 1001 be able to use other sources of measurement information and combine 1002 these with the available measurement data to determine a position. 1004 Note: The use of different sets of GNSS _assistance data_ can 1005 reduce the amount of time required for the signal acquisition 1006 stage and obviate the need for the receiver to extract data on the 1007 satellite constellation. Provision of assistance data is outside 1008 the scope of this document. 1010 Figure 12 shows an example of GNSS measurement data. The measurement 1011 shown is for the GPS system and includes measurement data for three 1012 satellites only. 1014 1016 1018 1019 499.9395 1020 0.87595747 1021 45 1022 1023 1024 378.2657 1025 0.56639479 1026 52 1027 1028 1029 -633.0309 1030 0.57016835 1031 48 1032 1033 1034 1036 Figure 12: Example GNSS Measurement 1038 Each "gnss" element represents a single set of GNSS measurement data, 1039 taken at a single point in time. Measurements taken at different 1040 times can be included in different "gnss" elements to enable 1041 iterative refinement of results. 1043 GNSS measurement parameters are described in more detail in the 1044 following sections. 1046 5.5.1. GNSS System and Signal 1048 The GNSS measurement structure is designed to be generic and to apply 1049 to different GNSS types. Different signals within those systems are 1050 also accounted for and can be measured separately. 1052 The GNSS type determines the time system that is used. An indication 1053 of the type of system and signal can ensure that the LIS is able to 1054 correctly use measurements. 1056 Measurements for multiple GNSS types and signals can be included by 1057 repeating the "gnss" element. 1059 This document creates an IANA registry for GNSS types. Two satellite 1060 systems are registered by this document: GPS [GPS.ICD] and Galileo 1061 [Galileo.ICD]. Details for the registry are included in Section 9.1. 1063 5.5.2. Time 1065 Each set of GNSS measurements is taken at a specific point in time. 1066 The "time" attribute is used to indicate the time that the 1067 measurement was acquired, if the receiver knows how the time system 1068 used by the GNSS relates to UTC time. 1070 Alternative to (or in addition to) the measurement time, the 1071 "gnssTime" element MAY be included. The "gnssTime" element includes 1072 a relative time in milliseconds using the time system native to the 1073 satellite system. For the GPS satellite system, the "gnssTime" 1074 element includes the time of week in milliseconds. For the Galileo 1075 system, the "gnssTime" element includes the time of day in 1076 milliseconds. 1078 The accuracy of the time measurement provided is critical in 1079 determining the accuracy of the location information derived from 1080 GNSS measurements. The receiver SHOULD indicate an estimated time 1081 error for any time that is provided. An RMS error can be included 1082 for the "gnssTime" element, with a value in milliseconds. 1084 5.5.3. Per-Satellite Measurement Data 1086 Multiple satellites are included in each set of GNSS measurements 1087 using the "sat" element. Each satellite is identified by a number in 1088 the "num" attribute. The satellite number is consistent with the 1089 identifier used in the given GNSS. 1091 Both the GPS and Galileo systems use satellite numbers between 1 and 1092 64. 1094 The GNSS receiver measures the following parameters for each 1095 satellite: 1097 doppler: The observed Doppler shift of the satellite signal, 1098 measured in meters per second. This is converted from a value in 1099 Hertz by the receiver to allow the measurement to be used without 1100 knowledge of the carrier frequency of the satellite system. This 1101 value permits the use of RMS error attributes, also measured in 1102 meters per second. 1104 codephase: The observed code phase for the satellite signal, 1105 measured in milliseconds. This is converted from the system- 1106 specific value of chips or wavelengths into a system independent 1107 value. Larger values indicate larger distances from satellite to 1108 receiver. This value permits the use of RMS error attributes, 1109 also measured in milliseconds. 1111 cn0: The signal to noise ratio for the satellite signal, measured in 1112 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 1113 dB-Hz. 1115 mp: An estimation of the amount of error that multipath signals 1116 contribute in meters. This parameter MAY be omitted. 1118 cq: An indication of the carrier quality. Two attributes are 1119 included: "continuous" can be either "true" or "false"; direct can 1120 be either "direct" or "inverted". This parameter MAY be omitted. 1122 adr: The accumulated Doppler range, measured in meters. This 1123 parameter MAY be omitted and is not useful unless multiple sets of 1124 GNSS measurements are provided or differential positioning is 1125 being performed. 1127 All values are converted from measures native to the satellite system 1128 to generic measures to ensure consistency of interpretation. Unless 1129 necessary, the schema does not constrain these values. 1131 5.5.4. GNSS Measurement Requests 1133 Measurement requests can include a "gnss" element, which includes the 1134 "system" and "signal" attributes. Multiple elements can be included 1135 to indicate a requests for GNSS measurements from multiple systems or 1136 signals. 1138 5.6. DSL Measurements 1140 Digital Subscriber Line (DSL) networks rely on a range of network 1141 technologies. DSL deployments regularly require cooperation between 1142 multiple organizations. These fall into two broad categories: 1143 infrastructure providers and Internet service providers (ISPs). For 1144 the same end user, an infrastructure and Internet service can be 1145 provided by different entities. Infrastructure providers manage the 1146 bulk of the physical infrastructure including cabling. End users 1147 obtain their service from an ISP, which manages all aspects visible 1148 to the end user including IP address allocation and operation of a 1149 LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL 1150 network deployments and the parameters that are available. 1152 Exchange of measurement information between these organizations is 1153 necessary for location information to be correctly generated. The 1154 ISP LIS needs to acquire location information from the infrastructure 1155 provider. However, since the infrastructure provider could have no 1156 knowledge of Device identifiers, it can only identify a stream of 1157 data that is sent to the ISP. This is resolved by passing 1158 measurement data relating to the Device to a LIS operated by the 1159 infrastructure provider. 1161 5.6.1. L2TP Measurements 1163 Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of 1164 linking the infrastructure provider and the ISP. The infrastructure 1165 provider LIS requires measurement data that identifies a single L2TP 1166 tunnel, from which it can generate location information. Figure 13 1167 shows an example L2TP measurement. 1169 1171 1172 1173 192.0.2.10 1174 192.0.2.61 1175 528 1176 1177 1178 1180 Figure 13: Example DSL L2TP Measurement 1182 5.6.2. RADIUS Measurements 1183 When authenticating network access, the infrastructure provider might 1184 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 1185 Access Node (AN). These messages provide the ISP RADIUS server with 1186 an identifier for the DSLAM or AN, plus the slot and port that the 1187 Device is attached to. These data can be provided as a measurement, 1188 which allows the infrastructure provider LIS to generate location 1189 information. 1191 The format of the AN, slot and port identifiers are not defined in 1192 the RADIUS protocol. Slot and port together identify a circuit on 1193 the AN, analogous to the circuit identifier in [RFC3046]. These 1194 items are provided directly, as they were in the RADIUS message. An 1195 example is shown in Figure 14. 1197 1199 1200 AN-7692 1201 3 1202 06 1203 1204 1206 Figure 14: Example DSL RADIUS Measurement 1208 5.6.3. Ethernet VLAN Tag Measurements 1210 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 1211 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 1212 used to identify the incoming residential circuit, while the S-TAG is 1213 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 1214 be used to identify a single point of network attachment. An example 1215 is shown in Figure 15. 1217 1219 1220 613 1221 1097 1222 1223 1225 Figure 15: Example DSL VLAN Tag Measurement 1227 Alternatively, the C-TAG can be replaced by data on the slot and port 1228 that the Device is attached to. This information might be included 1229 in RADIUS requests that are proxied from the infrastructure provider 1230 to the ISP RADIUS server. 1232 5.6.4. ATM Virtual Circuit Measurements 1234 An ATM virtual circuit can be employed between the ISP and 1235 infrastructure provider. Providing the virtual port ID (VPI) and 1236 virtual circuit ID (VCI) for the virtual circuit gives the 1237 infrastructure provider LIS the ability to identify a single data 1238 stream. A sample measurement is shown in Figure 16. 1240 1242 1243 55 1244 6323 1245 1246 1248 Figure 16: Example DSL ATM Measurement 1250 6. Privacy Considerations 1252 Location-related measurement data can be as privacy sensitive as 1253 location information [RFC6280]. 1255 Measurement data is effectively equivalent to location information if 1256 the contextual knowledge necessary to generate one from the other is 1257 readily accessible. Even where contextual knowledge is difficult to 1258 acquire, there can be no assurance that an authorized recipient of 1259 the contextual knowledge is also authorized to receive location 1260 information. 1262 In order to protect the privacy of the subject of location-related 1263 measurement data, measurement data MUST be protected with the same 1264 degree of protection as location information. The confidentiality 1265 and authentication provided by TLS MUST be used in order to convey 1266 measurement data over HELD [RFC5985]. Other protocols MUST provide 1267 comparable guarantees. 1269 6.1. Measurement Data Privacy Model 1271 It is not necessary to distribute measurement data in the same 1272 fashion as location information. Measurement data is less useful to 1273 location recipients than location information. A simple distribution 1274 model is described in this document. 1276 In this simple model, the Device is the only entity that is able to 1277 distribute measurement data. To use an analogy from the GEOPRIV 1278 architecture, the Device - as the Location Generator, or the 1279 Measurement Data Generator - is the sole entity that can act for the 1280 role of both Rule Maker and Location Server. 1282 A Device that provides location-related measurement data, MUST only 1283 do so as explicitly authorized by a Rule Maker. This depends on 1284 having an interface that allows Rule Makers (for instance, users or 1285 administrators) to control where and how measurement data is 1286 provided. 1288 No entity is permitted to redistribute measurement data. The Device 1289 directs other entities in how measurement data is used and retained. 1291 The GEOPRIV model [RFC6280] protects the location of a Target using 1292 direction provided by a Rule Maker. For the purposes of measurement 1293 data distribution, this model relies on the assumptions made in 1294 Section 3 of HELD [RFC5985]. These assumptions effectively declare 1295 the Device to be a proxy for both Target and Rule Maker. 1297 6.2. LIS Privacy Requirements 1299 A LIS MUST NOT reveal location-related measurement data to any other 1300 entity. A LIS MUST NOT reveal location information based on 1301 measurement data to any other entity unless directed to do so by the 1302 Device. 1304 By adding measurement data to a request for location information, the 1305 Device implicitly grants permission for the LIS to generate the 1306 requested location information using the measurement data. 1307 Permission to use this data for any other purpose is not implied. 1309 As long as measurement data is only used in serving the request that 1310 contains it, rules regarding data retention are not necessary. A LIS 1311 MUST discard location-related measurement data after servicing a 1312 request, unless the Device grants permission to use that information 1313 for other purposes. 1315 6.3. Measurement Data and Location URIs 1317 A LIS MAY use measurement data provided by the Device to serve 1318 requests to location URIs, if the Device permits it. A Device 1319 permits this by including measurement data in a request that 1320 explicitly requests a location URI. By requesting a location URI, 1321 the Device grants permission for the LIS to use the measurement data 1322 in serving requests to that location URI. The LIS cannot provide 1323 location recipients with measurement data, as defined in Section 6.1. 1325 Note: In HELD, the "any" type is not an explicit request for a 1326 location URI, though a location URI might be provided. 1328 The usefulness of measurement data that is provided in this fashion 1329 is limited. The measurement data is only valid at the time that it 1330 was acquired by the Device. At the time that a request is made to a 1331 location URI, the Device might have moved, rendering the measurement 1332 data incorrect. 1334 A Device is able to explicitly limit the time that a LIS retains 1335 measurement data by adding an expiry time to the measurement data. A 1336 LIS MUST NOT retain location-related measurement data in memory, 1337 storage or logs beyond the time indicated in the "expires" attribute 1338 (Section 4.1.2). A LIS MUST NOT retain measurement data if the 1339 "expires" attribute is absent. 1341 6.4. Third-Party-Provided Measurement Data 1343 An authorized third-party request for the location of a Device (see 1344 [RFC6155]) can include location-related measurement data. This is 1345 possible where the third-party is able to make observations about the 1346 Device. 1348 A third-party that provides measurement data MUST be authorized to 1349 provide the specific measurement for the identified device. A third- 1350 party MUST either be trusted by the LIS for the purposes of providing 1351 measurement data of the provided type, or the measurement data MUST 1352 be validated (see Section 7.2.1) before being used. 1354 How a third-party authenticates its identity or gains authorization 1355 to use measurement data is not covered by this document. 1357 7. Security Considerations 1359 Use of location-related measurement data has privacy considerations 1360 that are discussed in Section 6. 1362 7.1. Threat Model 1364 The threat model for location-related measurement data concentrates 1365 on the Device providing falsified, stolen or incorrect measurement 1366 data. 1368 A Device that provides location-related measurement data might use 1369 data to: 1371 o acquire the location of another Device, without authorization; 1372 o extract information about network topology; or 1374 o coerce the LIS into providing falsified location information based 1375 on the measurement data. 1377 Location-related measurement data describes the physical environment 1378 or network attachment of a Device. A third party adversary in the 1379 proximity of the Device might be able to alter the physical 1380 environment such that the Device provides measurement data that is 1381 controlled by the third party. This might be used to indirectly 1382 control the location information that is derived from measurement 1383 data. 1385 7.1.1. Acquiring Location Information Without Authorization 1387 Requiring authorization for location requests is an important part of 1388 privacy protections of a location protocol. A location configuration 1389 protocol usually operates under a restricted policy that allows a 1390 requester to obtain their own location. HELD identity extensions 1391 [RFC6155] allows other entities to be authorized, conditional on a 1392 Rule Maker providing sufficient authorization. 1394 The intent of these protections is to ensure that a location 1395 recipient is authorized to acquire location information. Location- 1396 related measurement data could be used by an attacker to circumvent 1397 such authorization checks if the association between measurement data 1398 and Target Device is not validated by a LIS. 1400 A LIS can be coerced into providing location information for a Device 1401 that a location recipient is not authorized to receive. A request 1402 identifies one Device (implicitly or explicitly), but measurement 1403 data is provided for another Device. If the LIS does not check that 1404 the measurement data is for the identified Device, it could 1405 incorrectly authorize the request. 1407 By using unverified measurement data to generate a response, the LIS 1408 provides information about a Device without appropriate 1409 authorization. 1411 The feasibility of this attack depends on the availability of 1412 information that links a Device with measurement data. In some 1413 cases, measurement data that is correlated with a target is readily 1414 available. For instance, LLDP measurements (Section 5.1) are 1415 broadcast to all nodes on the same network segment. An attacker on 1416 that network segment can easily gain measurement data that relates a 1417 Device with measurements. 1419 For some types of measurement data, it's necessary for an attacker to 1420 know the location of the target in order to determine what 1421 measurements to use. This attack is meaningless for types of 1422 measurement data that require that the attacker first know the 1423 location of the target before measurement data can be acquired or 1424 fabricated. GNSS measurements (Section 5.5) share this trait with 1425 many wireless location determination methods. 1427 7.1.2. Extracting Network Topology Data 1429 Allowing requests with measurements might be used to collect 1430 information about network topology. 1432 Network topology can be considered sensitive information by a network 1433 operator for commercial or security reasons. While it is impossible 1434 to completely prevent a Device from acquiring some knowledge of 1435 network topology if a location service is provided, a network 1436 operator might desire to limit how much of this information is made 1437 available. 1439 Mapping a network topology does not require that an attacker be able 1440 to associate measurement data with a particular Device. If a 1441 requester is able to try a number of measurements, it is possible to 1442 acquire information about network topology. 1444 It is not even necessary that the measurements are valid; random 1445 guesses are sufficient, provided that there is no penalty or cost 1446 associated with attempting to use the measurements. 1448 7.1.3. Exposing Network Topology Data 1450 A Device could reveal information about a network to entities outside 1451 of that network if it provides location measurement data to a LIS 1452 that is outside of that network. With the exception of GNSS 1453 measurements, the measurements in this document provide information 1454 about an access network that could reveal topology information to an 1455 unauthorized recipient. 1457 A Device MUST NOT provide information about network topology without 1458 a clear signal that the recipient is authorized. A LIS that is 1459 discovered using DHCP as described in LIS discovery [RFC5986] can be 1460 considered to be authorized to receive information about the access 1461 network. 1463 7.1.4. Lying By Proxy 1464 Location information is a function of its inputs, which includes 1465 measurement data. Thus, falsified measurement data can be used to 1466 alter the location information that is provided by a LIS. 1468 Some types of measurement data are relatively easy to falsify in a 1469 way that causes the resulting location information to be selected 1470 with little or no error. For instance, GNSS measurements are easy to 1471 use for this purpose because all the contextual information necessary 1472 to calculate a position using measurements is broadcast by the 1473 satellites [HARPER]. 1475 An attacker that falsifies measurement data gains little if they are 1476 the only recipients of the result. The attacker knows that the 1477 location information is bad. The attacker only gains if the 1478 information can somehow be attributed to the LIS by another location 1479 recipient. By coercing the LIS into providing falsified location 1480 information, any credibility that the LIS might have - that the 1481 attacker does not - is gained by the attacker. 1483 A third-party that is reliant on the integrity of the location 1484 information might base an evaluation of the credibility of the 1485 information on the source of the information. If that third party is 1486 able to attribute location information to the LIS, then an attacker 1487 might gain. 1489 Location information that is provided to the Device without any means 1490 to identify the LIS as its source is not subject to this attack. The 1491 Device is identified as the source of the data when it distributes 1492 the location information to location recipients. 1494 Location information is attributed to the LIS either through the use 1495 of digital signatures or by having the location recipient directly 1496 interact with the LIS. A LIS that digitally signs location 1497 information becomes identifiable as the source of the data. 1498 Similarly, the LIS is identified as a source of data if a location 1499 recipient acquires information directly from a LIS using a location 1500 URI. 1502 7.1.5. Measurement Replay 1503 The value of some measured properties do not change over time for a 1504 single location. For properties of a network, time-invariance is 1505 often directly as a result of the practicalities of operating the 1506 network. Limiting the changes to a network ensures greater 1507 consistency of service. A largely static network also greatly 1508 simplifies the data management tasks involved with providing a 1509 location service. However, time invariant properties allow for 1510 simple replay attacks, where an attacker acquires measurements that 1511 can later be used without being detected as being invalid. 1513 Measurement data is frequently an observation of an time-invariant 1514 property of the environment at the subject location. For 1515 measurements of this nature, nothing in the measurement itself is 1516 sufficient proof that the Device is present at the resulting 1517 location. Measurement data might have been previously acquired and 1518 reused. 1520 For instance, the identity of a radio transmitter, if broadcast by 1521 that transmitter, can be collected and stored. An attacker that 1522 wishes it known that they exist at a particular location, can claim 1523 to observe this transmitter at any time. Nothing inherent in the 1524 claim reveals it to be false. 1526 7.1.6. Environment Spoofing 1528 Some types of measurement data can be altered or influenced by a 1529 third party so that a Device unwittingly provides falsified data. If 1530 it is possible for a third party to alter the measured phenomenon, 1531 then any location information that is derived from this data can be 1532 indirectly influenced. 1534 Altering the environment in this fashion might not require 1535 involvement with either Device or LIS. Measurement that is passive - 1536 where the Device observes a signal or other phenomenon without direct 1537 interaction - are most susceptible to alteration by third parties. 1539 Measurement of radio signal characteristics is especially vulnerable 1540 since an adversary need only be in the general vicinity of the Device 1541 and be able to transmit a signal. For instance, a GNSS spoofer is 1542 able to produce fake signals that claim to be transmitted by any 1543 satellite or set of satellites (see [GPS.SPOOF]). 1545 Measurements that require direct interaction increases the complexity 1546 of the attack. For measurements relating to the communication 1547 medium, a third party cannot avoid direct interaction, they need only 1548 be on the communications path (that is, man in the middle). 1550 Even if the entity that is interacted with is authenticated, this 1551 does not provide any assurance about the integrity of measurement 1552 data. For instance, the Device might authenticate the identity of a 1553 radio transmitter through the use of cryptographic means and obtain 1554 signal strength measurements for that transmitter. Radio signal 1555 strength is trivial for an attacker to increase simply by receiving 1556 and amplifying the raw signal; it is not necessary for the attacker 1557 to be able to understand the signal content. 1559 Note: This particular "attack" is more often completely legitimate. 1560 Radio repeaters are commonplace mechanism used to increase radio 1561 coverage. 1563 Attacks that rely on altering the observed environment of a Device 1564 require countermeasures that affect the measurement process. For 1565 radio signals, countermeasures could include the use of authenticated 1566 signals, or altered receiver design. In general, countermeasures are 1567 highly specific to the individual measurement process. An exhaustive 1568 discussion of these issues is left to the relevant literature for 1569 each measurement technology. 1571 A Device that provides measurement data is assumed to be responsible 1572 for applying appropriate countermeasures against this type of attack. 1574 Where a Device is the sole recipient of location information derived 1575 from measurement data, a LIS might choose to provide location 1576 information without any validation. The responsibility for ensuring 1577 the veracity of the measurement data lies with the Device. 1579 Measurement data that is susceptible to this sort of influence SHOULD 1580 be treated as though it were produced by an untrusted Device for 1581 those cases where a location recipient might attribute the location 1582 information to the LIS. GNSS measurements and radio signal strength 1583 measurements can be affected relatively cheaply, though almost all 1584 other measurement types can be affected with varying costs to an 1585 attacker, with the largest cost often being a requirement for 1586 physical access. To the extent that it is feasible, measurement data 1587 SHOULD be subjected to the same validation as for other types of 1588 attacks that rely on measurement falsification. 1590 Note: Altered measurement data might be provided by a Device that 1591 has no knowledge of the alteration. Thus, an otherwise trusted 1592 Device might still be an unreliable source of measurement data. 1594 7.2. Mitigation 1595 The following measures can be applied to limit or prevent attacks. 1596 The effectiveness of each depends on the type of measurement data and 1597 how that measurement data is acquired. 1599 Two general approaches are identified for dealing with untrusted 1600 measurement data: 1602 1. Require independent validation of measurement data or the 1603 location information that is produced. 1605 2. Identify the types of sources that provided the measurement data 1606 that location information was derived from. 1608 This section goes into more detail on the different forms of 1609 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The 1610 impact of attributing location information to sources is discussed in 1611 more detail in Section 7.2.4. 1613 Any costs in validation are balanced against the degree of integrity 1614 desired from the resulting location information. 1616 7.2.1. Measurement Validation 1618 Detecting that measurement data has been falsified is difficult in 1619 the absence of integrity mechanisms. 1621 Independent confirmation of the veracity of measurement data ensures 1622 that the measurement is accurate and that it applies to the correct 1623 Device. When it's possible to gather the same measurement data from 1624 a trusted and independent source without undue expense, the LIS can 1625 use the trusted data in place of what the untrusted Device has sent. 1626 In cases where that is impractical, the untrusted data can provide 1627 hints that allow corroboration of the data (see Section 7.2.1.1). 1629 Measurement information might contain no inherent indication that it 1630 is falsified. On the contrary, it can be difficult to obtain 1631 information that would provide any degree of assurance that the 1632 measurement device is physically at any particular location. 1633 Measurements that are difficult to verify require other forms of 1634 assurance before they can be used. 1636 7.2.1.1. Effectiveness 1638 Measurement validation MUST be used if measurement data for a 1639 particular Device can be easily acquired by unauthorized location 1640 recipients, as described in Section 7.1.1. This prevents 1641 unauthorized access to location information using measurement data. 1643 Validation of measurement data can be significantly more effective 1644 than independent acquisition of the same. For instance, a Device in 1645 a large Ethernet network could provide a measurement indicating its 1646 point of attachment using LLDP measurements. For a LIS, acquiring 1647 the same measurement data might require a request to all switches in 1648 that network. With the measurement data, validation can target the 1649 identified switch with a specific query. 1651 Validation is effective in identifying falsified measurement data 1652 (Section 7.1.4), including attacks involving replay of measurement 1653 data (Section 7.1.5). Validation also limits the amount of network 1654 topology information (Section 7.1.2) made available to Devices to 1655 that portion of the network topology that they are directly attached. 1657 Measurement validation has no effect if the underlying effect is 1658 being spoofed (Section 7.1.6). 1660 7.2.1.2. Limitations (Unique Observer) 1662 A Device is often in a unique position to make a measurement. It 1663 alone occupies the point in space-time that the location 1664 determination process seeks to determine. The Device becomes a 1665 unique observer for a particular property. 1667 The ability of the Device to become a unique observer makes the 1668 Device invaluable to the location determination process. As a unique 1669 observer, it also makes the claims of a Device difficult to validate 1670 and easily to spoof. 1672 As long as no other entity is capable of making the same 1673 measurements, there is also no other entity that can independently 1674 check that the measurements are correct and applicable to the Device. 1675 A LIS might be unable to validate all or part of the measurement data 1676 it receives from a unique observer. For instance, a signal strength 1677 measurement of the signal from a radio tower cannot be validated 1678 directly. 1680 Some portion of the measurement data might still be independently 1681 verified, even if all information cannot. In the previous example, 1682 the radio tower might be able to provide verification that the Device 1683 is present if it is able to observe a radio signal sent by the 1684 Device. 1686 If measurement data can only be partially validated, the extent to 1687 which it can be validated determines the effectiveness of validation 1688 against these attacks. 1690 The advantage of having the Device as a unique observer is that it 1691 makes it difficult for an attacker to acquire measurements without 1692 the assistance of the Device. Attempts to use measurements to gain 1693 unauthorized access to measurement data (Section 7.1.1) are largely 1694 ineffectual against a unique observer. 1696 7.2.2. Location Validation 1698 Location information that is derived from location-related 1699 measurement data can also be verified against trusted location 1700 information. Rather than validating inputs to the location 1701 determination process, suspect locations are identified at the output 1702 of the process. 1704 Trusted location information is acquired using sources of measurement 1705 data that are trusted. Untrusted location information is acquired 1706 using measurement data provided from untrusted sources, which might 1707 include the Device. These two locations are compared. If the 1708 untrusted location agrees with the trusted location, the untrusted 1709 location information is used. 1711 Algorithms for the comparison of location information are not 1712 included in this document. However, a simple comparison for 1713 agreement might require that the untrusted location be entirely 1714 contained within the uncertainty region of the trusted location. 1716 There is little point in using a less accurate, less trusted 1717 location. Untrusted location information that has worse accuracy 1718 than trusted information can be immediately discarded. There are 1719 multiple factors that affect accuracy, uncertainty and currency being 1720 the most important. How location information is compared for 1721 accuracy is not defined in this document. 1723 7.2.2.1. Effectiveness 1725 Location validation limits the extent to which falsified - or 1726 erroneous - measurement data can cause an incorrect location to be 1727 reported. 1729 Location validation can be more efficient than validation of inputs, 1730 particularly for a unique observer (Section 7.2.1.2). 1732 Validating location ensures that the Device is at or near the 1733 resulting location. Location validation can be used to limit or 1734 prevent all of the attacks identified in this document. 1736 7.2.2.2. Limitations 1737 The trusted location that is used for validation is always less 1738 accurate than the location that is being checked. The amount by 1739 which the untrusted location is more accurate, is the same amount 1740 that an attacker can exploit. 1742 For example, a trusted location might indicate a five kilometer 1743 radius uncertainty region. An untrusted location that describes a 1744 100 meter uncertainty within the larger region might be accepted as 1745 more accurate. An attacker might still falsify measurement data to 1746 select any location within the larger uncertainty region. While the 1747 100 meter uncertainty that is reported seems more accurate, a 1748 falsified location could be anywhere in the five kilometer region. 1750 Where measurement data might have been falsified, the actual 1751 uncertainty is effectively much higher. Local policy might allow 1752 differing degrees of trust to location information derived from 1753 untrusted measurement data. This might be a boolean operation with 1754 only two possible outcomes: untrusted location information might be 1755 used entirely or not at all. Alternatively, untrusted location could 1756 be combined with trusted location information using different 1757 weightings, based on a value set in local policy. 1759 7.2.3. Supporting Observations 1761 Replay attacks using previously acquired measurement data are 1762 particularly hard to detect without independent validation. Rather 1763 than validate the measurement data directly, supplementary data might 1764 be used to validate measurements or the location information derived 1765 from those measurements. 1767 These supporting observations could be used to convey information 1768 that provides additional assurance that the Device was acquired at a 1769 specific time and place. In effect, the Device is requested to 1770 provide proof of its presence at the resulting location. 1772 For instance, a Device that measures attributes of a radio signal 1773 could also be asked to provide a sample of the measured radio signal. 1774 If the LIS is able to observe the same signal, the two observations 1775 could be compared. Providing that the signal cannot be predicted in 1776 advance by the Device, this could be used to support the claim that 1777 the Device is able to receive the signal. Thus, the Device is likely 1778 to be within the range that the signal is transmitted. A LIS could 1779 use this to attribute a higher level of trust in the associated 1780 measurement data or resulting location. 1782 7.2.3.1. Effectiveness 1783 The use of supporting observations is limited by the ability of the 1784 LIS to acquire and validate these observations. The advantage of 1785 selecting observations independent of measurement data is that 1786 observations can be selected based on how readily available the data 1787 is for both LIS and Device. The amount and quality of the data can 1788 be selected based on the degree of assurance that is desired. 1790 Use of supporting observations is similar to both measurement 1791 validation and location validation. All three methods rely on 1792 independent validation of one or more properties. Applicability of 1793 each method is similar. 1795 Use of supporting observations can be used to limit or prevent all of 1796 the attacks identified in this document. 1798 7.2.3.2. Limitations 1800 The effectiveness of the validation method depends on the quality of 1801 the supporting observation: how hard it is to obtain at a different 1802 time or place, how difficult it is to guess, and what other costs 1803 might be involved in acquiring this data. 1805 In the example of an observed radio signal, requesting a sample of 1806 the signal only provides an assurance that the Device is able to 1807 receive the signal transmitted by the measured radio transmitter. 1808 This only provides some assurance that the Device is within range of 1809 the transmitter. 1811 As with location validation, a Device might still be able to provide 1812 falsified measurements that could alter the value of the location 1813 information as long as the result is within this region. 1815 Requesting additional supporting observations can reduce the size of 1816 the region over which location information can be altered by an 1817 attacker, or increase trust in the result, but each additional 1818 measurement imposes an acquisition cost. Supporting observations 1819 contribute little or nothing toward the primary goal of determining 1820 the location of the Device. 1822 7.2.4. Attribution 1824 Lying by proxy (Section 7.1.4) relies on the location recipient being 1825 able to attribute location information to a LIS. The effectiveness 1826 of this attack is negated if location information is explicitly 1827 attributed to a particular source. 1829 This requires an extension to the location object that explicitly 1830 identifies the source (or sources) of each item of location 1831 information. 1833 Rather than relying on a process that seeks to ensure that location 1834 information is accurate, this approach instead provides a location 1835 recipient with the information necessary to reach their own 1836 conclusion about the trustworthiness of the location information. 1838 Including an authenticated identity for all sources of measurement 1839 data presents a number of technical and operational challenges. It 1840 is possible that the LIS has a transient relationship with a Device. 1841 A Device is not expected to share authentication information with a 1842 LIS. There is no assurance that Device identification is usable by a 1843 potential location recipient. Privacy concerns might also prevent 1844 the sharing identification information, even if it were available and 1845 usable. 1847 Identifying the type of measurement source allows a location 1848 recipient to make a decision about the trustworthiness of location 1849 information without depending on having authenticated identity 1850 information for each source. An element for this purpose is defined 1851 in Section 4.4. 1853 When including location information that is based on measurement data 1854 from sources that might be untrusted, a LIS SHOULD include 1855 alternative location information that is derived from trusted sources 1856 of measurement data. Each item of location information can then be 1857 labelled with the source of that data. 1859 A location recipient that is able to identify a specific source of 1860 measurement data (whether it be LIS or Device) can use this 1861 information to attribute location information to either or both 1862 entity. The location recipient is then better able to make decisions 1863 about trustworthiness based on the source of the data. 1865 A location recipient that does not understand the "source" element is 1866 unable to make this distinction. When constructing a PIDF-LO 1867 document, trusted location information MUST be placed in the PIDF-LO 1868 so that it is given higher priority to any untrusted location 1869 information according to Rule #8 of [RFC5491]. 1871 Attribution of information does nothing to address attacks that alter 1872 the observed parameters that are used in location determination 1873 (Section 7.1.6). 1875 7.2.5. Stateful Correlation of Location Requests 1876 Stateful examination of requests can be used to prevent a Device from 1877 attempting to map network topology using requests for location 1878 information (Section 7.1.2). 1880 Simply limiting the rate of requests from a single Device reduces the 1881 amount of data that a Device can acquire about network topology. A 1882 LIS could also make observations about the movements of a Device. A 1883 Device that is attempting to gather topology information is likely to 1884 be assigned a location that changes significantly between subsequent 1885 requests, possibly violating physical laws (or lower limits that 1886 might still be unlikely) with respect to speed and acceleration. 1888 7.3. An Unauthorized or Compromised LIS 1890 A compromised LIS, or a compromise in LIS discovery [RFC5986] could 1891 lead to an unathorized entity obtaining measurement data. This 1892 information could then be used or redistributed. A Device MUST 1893 ensure that it authenticate a LIS, as described in Section 9 of 1894 [RFC5985]. 1896 An entity that is able to acquire measurement data can, in addition 1897 to using those measurements to learn the location of a Device, also 1898 use that information for other purposes. This information can be 1899 used to provide insight into network topology (Section 7.1.2). 1901 Measurement data might also be exploited in other ways. For example, 1902 revealing the type of 802.11 transceiver that a Device uses could 1903 allow an attacker to use specific vulnerabilities to attack a Device. 1904 Similarly, revealing information about network elements could enable 1905 targeted attacks on that infrastructure. 1907 8. Measurement Schemas 1909 The schema are broken up into their respective functions. There is a 1910 base container schema into which all measurements are placed, plus 1911 definitions for a measurement request (Section 8.1). A PIDF-LO 1912 extension is defined in a separate schema (Section 8.2). There is a 1913 basic types schema, that contains various base type definitions for 1914 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and 1915 MAC addresses (Section 8.3). Then each of the specific measurement 1916 types is defined in its own schema. 1918 8.1. Measurement Container Schema 1920 1921 1929 1930 1932 1933 1934 1936 This schema defines a framework for location measurements. 1937 1938 1940 1942 1943 1944 1945 1946 1947 1949 1950 1951 1952 1953 1954 1955 1956 1957 1959 1961 1962 1963 1964 1965 1967 1969 1970 1971 1973 1975 1976 1977 1978 1979 1980 1982 1983 1984 1985 1986 1987 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2004 Measurement Container Schema 2006 8.2. Measurement Source Schema 2008 2009 2016 2017 2019 2020 2021 2023 This schema defines an extension to PIDF-LO that indicates the 2024 type of source that produced the measurement data used in 2025 generating the associated location information. 2026 2027 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2043 Measurement Source PIDF-LO Extension Schema 2045 8.3. Base Type Schema 2047 Note that the pattern rules in the following schema wrap due to 2048 length constraints. None of the patterns contain whitespace. 2050 2051 2058 2059 2061 2062 2063 2065 This schema defines a set of base type elements. 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2108 2109 2110 2112 2113 2114 2115 2117 An IP version 6 address, based on RFC 4291. 2118 2119 2120 2121 2122 2123 2124 2125 2126 2128 2130 2132 2134 2136 2138 2139 2140 2141 2149 2150 2151 2152 2154 2155 2156 2157 2161 2162 2164 2165 2166 2167 2169 2170 2172 2174 Base Type Schema 2176 8.4. LLDP Measurement Schema 2178 2179 2187 2188 2190 2191 2192 2194 This schema defines a set of LLDP location measurements. 2195 2196 2198 2200 2201 2202 2203 2204 2205 2206 2207 2209 2210 2211 2212 2214 2216 2217 2218 2219 2221 2222 2223 2225 2226 2227 2228 2229 2230 2232 2234 LLDP measurement schema 2236 8.5. DHCP Measurement Schema 2238 2239 2247 2248 2250 2251 2252 2254 This schema defines a set of DHCP location measurements. 2255 2256 2258 2260 2261 2262 2263 2264 2265 2266 2267 2269 2271 2273 2275 2276 2277 2278 2279 2281 2282 2283 2284 2286 2287 2288 2290 2292 DHCP measurement schema 2294 8.6. WiFi Measurement Schema 2296 2297 2306 2307 2309 802.11 location measurements 2311 2312 2313 2315 This schema defines a basic set of 802.11 location measurements. 2316 2317 2319 2320 2322 2324 2325 2326 2327 2328 2330 2332 2333 2334 2335 2336 2338 2339 2340 2341 2342 2343 2345 2347 2349 2351 2353 2355 2357 2360 2362 2364 2365 2367 2368 2369 2370 2372 2373 2374 2375 2377 2378 2379 2381 2383 2384 2385 2386 2387 2389 2390 2391 2392 2393 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2414 2415 2416 2417 2418 2420 2421 2423 2425 2427 2428 2429 2430 2432 2433 2434 2435 2436 2437 2438 2440 2441 2442 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2457 2458 2460 2462 WiFi measurement schema 2464 8.7. Cellular Measurement Schema 2466 2467 2474 2475 2477 2478 2479 2481 This schema defines a set of cellular location measurements. 2482 2483 2485 2487 2488 2489 2490 2491 2492 2493 2494 2495 2497 2498 2499 2500 2501 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2522 2523 2524 2525 2526 2527 2529 2530 2532 2533 2534 2535 2537 2538 2539 2540 2541 2543 2544 2545 2546 2547 2549 2550 2551 2552 2554 2556 2558 2559 2560 2561 2562 2563 2564 2565 2566 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2583 2585 Cellular measurement schema 2587 8.8. GNSS Measurement Schema 2589 2590 2598 2599 2601 2602 2603 2605 This schema defines a set of GNSS location measurements 2606 2607 2609 2611 2612 2613 2614 2615 2616 2617 2619 2620 2621 2622 2623 2625 2627 2629 2630 2631 2632 2633 2634 2635 2637 2638 2639 2640 2641 2642 2644 2645 2647 2649 2651 2652 2654 2655 2656 2658 2659 2660 2661 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2676 GNSS measurement Schema 2678 8.9. DSL Measurement Schema 2680 2681 2689 2690 2692 DSL measurement definitions 2693 2694 2695 2697 This schema defines a basic set of DSL location measurements. 2698 2700 2702 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2760 2762 DSL measurement schema 2764 9. IANA Considerations 2766 This section creates a registry for GNSS types (Section 5.5) and 2767 registers the namespaces and schema defined in Section 8. 2769 9.1. IANA Registry for GNSS Types 2771 This document establishes a new IANA registry for "Global Navigation 2772 Satellite System (GNSS) types". The registry includes tokens for the 2773 GNSS type and for each of the signals within that type. Referring to 2774 [RFC5226], this registry operates under "Specification Required" 2775 rules. The IESG will appoint an Expert Reviewer who will advise IANA 2776 promptly on each request for a new or updated GNSS type. 2778 Each entry in the registry requires the following information: 2780 GNSS name: the name of the GNSS 2782 Brief description: a brief description of the GNSS 2784 GNSS token: a token that can be used to identify the GNSS 2786 Signals: a set of tokens that represent each of the signals that the 2787 system provides 2789 Documentation reference: a reference to one or more stable, public 2790 specifications that outline usage of the GNSS, including (but not 2791 limited to) signal specifications and time systems 2793 The registry initially includes two registrations: 2795 GNSS name: Global Positioning System (GPS) 2796 Brief description: a system of satellites that use spread-spectrum 2797 transmission, operated by the US military for commercial and 2798 military applications 2800 GNSS token: gps 2802 Signals: L1, L2, L1C, L2C, L5 2804 Documentation reference: Navstar GPS Space Segment/Navigation User 2805 Interface [GPS.ICD] 2807 GNSS name: Galileo 2809 Brief description: a system of satellites that operate in the same 2810 spectrum as GPS, operated by the European Union for commercial 2811 applications 2813 GNSS Token: galileo 2815 Signals: L1, E5A, E5B, E5A+B, E6 2817 Documentation Reference: Galileo Open Service Signal In Space 2818 Interface Control Document (SIS ICD) [Galileo.ICD] 2820 9.2. URN Sub-Namespace Registration for 2821 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2823 This section registers a new XML namespace, 2824 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines 2825 in [RFC3688]. 2827 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2829 Registrant Contact: IETF, GEOPRIV working group, 2830 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2832 XML: 2834 BEGIN 2835 2836 2838 2839 2840 Measurement Source for PIDF-LO 2841 2842 2843

Namespace for Location Measurement Source

2844

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

2845 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2846 with the RFC number for this specification.]] 2847

See RFCXXXX.

2848 2849 2850 END 2852 9.3. URN Sub-Namespace Registration for 2853 urn:ietf:params:xml:ns:geopriv:lm 2855 This section registers a new XML namespace, 2856 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 2857 [RFC3688]. 2859 URI: urn:ietf:params:xml:ns:geopriv:lm 2861 Registrant Contact: IETF, GEOPRIV working group, 2862 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2864 XML: 2866 BEGIN 2867 2868 2870 2871 2872 Measurement Container 2873 2874 2875

Namespace for Location Measurement Container

2876

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

2877 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2878 with the RFC number for this specification.]] 2879

See RFCXXXX.

2880 2881 2882 END 2884 9.4. URN Sub-Namespace Registration for 2885 urn:ietf:params:xml:ns:geopriv:lm:basetypes 2887 This section registers a new XML namespace, 2888 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 2889 in [RFC3688]. 2891 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 2893 Registrant Contact: IETF, GEOPRIV working group, 2894 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2896 XML: 2898 BEGIN 2899 2900 2902 2903 2904 Base Device Types 2905 2906 2907

Namespace for Base Types

2908

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

2909 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2910 with the RFC number for this specification.]] 2911

See RFCXXXX.

2912 2913 2914 END 2916 9.5. URN Sub-Namespace Registration for 2917 urn:ietf:params:xml:ns:geopriv:lm:lldp 2919 This section registers a new XML namespace, 2920 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 2921 [RFC3688]. 2923 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 2925 Registrant Contact: IETF, GEOPRIV working group, 2926 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2928 XML: 2930 BEGIN 2931 2932 2934 2935 2936 LLDP Measurement Set 2937 2938 2939

Namespace for LLDP Measurement Set

2940

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

2941 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2942 with the RFC number for this specification.]] 2943

See RFCXXXX.

2944 2945 2946 END 2948 9.6. URN Sub-Namespace Registration for 2949 urn:ietf:params:xml:ns:geopriv:lm:dhcp 2951 This section registers a new XML namespace, 2952 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 2953 [RFC3688]. 2955 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 2957 Registrant Contact: IETF, GEOPRIV working group, 2958 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2960 XML: 2962 BEGIN 2963 2964 2966 2967 2968 DHCP Measurement Set 2969 2970 2971

Namespace for DHCP Measurement Set

2972

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

2973 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2974 with the RFC number for this specification.]] 2975

See RFCXXXX.

2976 2978 2979 END 2981 9.7. URN Sub-Namespace Registration for 2982 urn:ietf:params:xml:ns:geopriv:lm:wifi 2984 This section registers a new XML namespace, 2985 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 2986 [RFC3688]. 2988 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 2990 Registrant Contact: IETF, GEOPRIV working group, 2991 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2993 XML: 2995 BEGIN 2996 2997 2999 3000 3001 WiFi Measurement Set 3002 3003 3004

Namespace for WiFi Measurement Set

3005

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

3006 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3007 with the RFC number for this specification.]] 3008

See RFCXXXX.

3009 3010 3011 END 3013 9.8. URN Sub-Namespace Registration for 3014 urn:ietf:params:xml:ns:geopriv:lm:cell 3016 This section registers a new XML namespace, 3017 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 3018 [RFC3688]. 3020 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 3022 Registrant Contact: IETF, GEOPRIV working group, 3023 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 3025 XML: 3027 BEGIN 3028 3029 3031 3032 3033 Cellular Measurement Set 3034 3035 3036

Namespace for Cellular Measurement Set

3037

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

3038 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3039 with the RFC number for this specification.]] 3040

See RFCXXXX.

3041 3042 3043 END 3045 9.9. URN Sub-Namespace Registration for 3046 urn:ietf:params:xml:ns:geopriv:lm:gnss 3048 This section registers a new XML namespace, 3049 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 3050 [RFC3688]. 3052 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 3054 Registrant Contact: IETF, GEOPRIV working group, 3055 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 3057 XML: 3059 BEGIN 3060 3061 3063 3064 3065 GNSS Measurement Set 3066 3067 3068

Namespace for GNSS Measurement Set

3069

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

3070 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3071 with the RFC number for this specification.]] 3072

See RFCXXXX.

3073 3074 3075 END 3077 9.10. URN Sub-Namespace Registration for 3078 urn:ietf:params:xml:ns:geopriv:lm:dsl 3080 This section registers a new XML namespace, 3081 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 3082 [RFC3688]. 3084 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 3086 Registrant Contact: IETF, GEOPRIV working group, 3087 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 3089 XML: 3091 BEGIN 3092 3093 3095 3096 3097 DSL Measurement Set 3098 3099 3100

Namespace for DSL Measurement Set

3101

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

3102 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3103 with the RFC number for this specification.]] 3104

See RFCXXXX.

3105 3106 3107 END 3109 9.11. XML Schema Registration for Measurement Source Schema 3111 This section registers an XML schema as per the guidelines in 3112 [RFC3688]. 3114 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc 3116 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3117 Martin Thomson (martin.thomson@commscope.com). 3119 Schema: The XML for this schema can be found in Section 8.2 of this 3120 document. 3122 9.12. XML Schema Registration for Measurement Container Schema 3124 This section registers an XML schema as per the guidelines in 3125 [RFC3688]. 3127 URI: urn:ietf:params:xml:schema:lm 3129 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3130 Martin Thomson (martin.thomson@commscope.com). 3132 Schema: The XML for this schema can be found in Section 8.1 of this 3133 document. 3135 9.13. XML Schema Registration for Base Types Schema 3137 This section registers an XML schema as per the guidelines in 3138 [RFC3688]. 3140 URI: urn:ietf:params:xml:schema:lm:basetypes 3142 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3143 Martin Thomson (martin.thomson@commscope.com). 3145 Schema: The XML for this schema can be found in Section 8.3 of this 3146 document. 3148 9.14. XML Schema Registration for LLDP Schema 3150 This section registers an XML schema as per the guidelines in 3151 [RFC3688]. 3153 URI: urn:ietf:params:xml:schema:lm:lldp 3155 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3156 Martin Thomson (martin.thomson@commscope.com). 3158 Schema: The XML for this schema can be found in Section 8.4 of this 3159 document. 3161 9.15. XML Schema Registration for DHCP Schema 3163 This section registers an XML schema as per the guidelines in 3164 [RFC3688]. 3166 URI: urn:ietf:params:xml:schema:lm:dhcp 3167 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3168 Martin Thomson (martin.thomson@commscope.com). 3170 Schema: The XML for this schema can be found in Section 8.5 of this 3171 document. 3173 9.16. XML Schema Registration for WiFi Schema 3175 This section registers an XML schema as per the guidelines in 3176 [RFC3688]. 3178 URI: urn:ietf:params:xml:schema:lm:wifi 3180 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3181 Martin Thomson (martin.thomson@commscope.com). 3183 Schema: The XML for this schema can be found in Section 8.6 of this 3184 document. 3186 9.17. XML Schema Registration for Cellular Schema 3188 This section registers an XML schema as per the guidelines in 3189 [RFC3688]. 3191 URI: urn:ietf:params:xml:schema:lm:cellular 3193 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3194 Martin Thomson (martin.thomson@commscope.com). 3196 Schema: The XML for this schema can be found in Section 8.7 of this 3197 document. 3199 9.18. XML Schema Registration for GNSS Schema 3201 This section registers an XML schema as per the guidelines in 3202 [RFC3688]. 3204 URI: urn:ietf:params:xml:schema:lm:gnss 3206 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3207 Martin Thomson (martin.thomson@commscope.com). 3209 Schema: The XML for this schema can be found in Section 8.8 of this 3210 document. 3212 9.19. XML Schema Registration for DSL Schema 3213 This section registers an XML schema as per the guidelines in 3214 [RFC3688]. 3216 URI: urn:ietf:params:xml:schema:lm:dsl 3218 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3219 Martin Thomson (martin.thomson@commscope.com). 3221 Schema: The XML for this schema can be found in Section 8.9 of this 3222 document. 3224 10. Acknowledgements 3226 Thanks go to Simon Cox for his comments relating to terminology that 3227 have helped ensure that this document is aligned with ongoing work in 3228 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 3229 review and comments on the GNSS sections of this document. Thanks to 3230 Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti 3231 for their significant input to and suggestions for improving the 3232 802.11 measurements. Thanks to Cullen Jennings for feedback and 3233 suggestions. Bernard Aboba provided review and feedback on a range 3234 of measurement data definitions. Mary Barnes and Geoff Thompson 3235 provided a review and corrections. David Waitzman and John Bressler 3236 both noted shortcomings with 802.11 measurements. Keith Drage, 3237 Darren Pawson provided expert LTE knowledge. 3239 11. References 3241 11.1. Normative References 3243 [ASCII] , "US-ASCII. Coded Character Set - 7-Bit American Standard 3244 Code for Information Interchange. Standard ANSI X3.4-1986, 3245 ANSI, 1986.", . 3247 [GPS.ICD] , "Navstar GPS Space Segment/Navigation User Interface", 3248 ICD GPS-200, Apr 2000. 3250 [Galileo.ICD] 3251 GJU, "Galileo Open Service Signal In Space Interface 3252 Control Document (SIS ICD)", May 2006. 3254 [IANA.enterprise] 3255 IANA, "Private Enterprise Numbers", 2011, 3256 . 3258 [IEEE.80211] 3259 IEEE, "Wireless LAN Medium Access Control (MAC) and 3260 Physical Layer (PHY) specifications", IEEE Std 3261 802.11-2012, March 2012. 3263 [IEEE.8021AB] 3264 IEEE, "IEEE Standard for Local and Metropolitan area 3265 networks, Station and Media Access Control Connectivity 3266 Discovery", IEEE Std 802.1AB-2009, September 2009. 3268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3269 Requirement Levels", BCP 14, RFC 2119, March 1997. 3271 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3272 3046, January 2001. 3274 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 3275 and M. Carney, "Dynamic Host Configuration Protocol for 3276 IPv6 (DHCPv6)", RFC 3315, July 2003. 3278 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3279 10646", STD 63, RFC 3629, November 2003. 3281 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3282 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3283 3986, January 2005. 3285 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 3286 Suboption for the Dynamic Host Configuration Protocol 3287 (DHCP) Relay Agent Option", RFC 3993, March 2005. 3289 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3290 Format", RFC 4119, December 2005. 3292 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3293 Architecture", RFC 4291, February 2006. 3295 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3296 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 3297 2006. 3299 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3300 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 3301 2006. 3303 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3304 Presence Information Data Format Location Object (PIDF-LO) 3305 Usage Clarification, Considerations, and Recommendations", 3306 RFC 5491, March 2009. 3308 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3309 Address Text Representation", RFC 5952, August 2010. 3311 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3312 5985, September 2010. 3314 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 3315 Location Information Server (LIS)", RFC 5986, September 3316 2010. 3318 [TIA-2000.5] 3319 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for 3320 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March 3321 2004. 3323 [TS.3GPP.23.003] 3324 3GPP, "Numbering, addressing and identification", 3GPP TS 3325 23.003 9.4.0, September 2010. 3327 11.2. Informative References 3329 [ANSI-TIA-1057] 3330 ANSI/TIA, "Link Layer Discovery Protocol for Media 3331 Endpoint Devices", TIA 1057, April 2006. 3333 [DSL.TR025] 3334 Wang, R., "Core Network Architecture Recommendations for 3335 Access to Legacy Data Networks over ADSL", September 1999. 3337 [DSL.TR101] 3338 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 3339 Aggregation", April 2006. 3341 [GPS.SPOOF] 3342 Scott, L., "Anti-Spoofing and Authenticated Signal 3343 Architectures for Civil Navigation Signals", ION-GNSS 3344 Portland, Oregon, 2003. 3346 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side 3347 spoofing and detection for Assisted-GPS", Proceedings of 3348 International Global Navigation Satellite Systems Society 3349 (IGNSS) Symposium 2009 16, December 2009, 3350 . 3352 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 3353 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 3354 RFC 2661, August 1999. 3356 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3357 "Remote Authentication Dial In User Service (RADIUS)", RFC 3358 2865, June 2000. 3360 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3361 January 2004. 3363 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 3364 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 3366 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3367 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3368 May 2008. 3370 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 3371 Barnes, "Use of Device Identity in HTTP-Enabled Location 3372 Delivery (HELD)", RFC 6155, March 2011. 3374 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 3375 Tschofenig, H., and H. Schulzrinne, "An Architecture for 3376 Location and Location Privacy in Internet Applications", 3377 BCP 160, RFC 6280, July 2011. 3379 Authors' Addresses 3381 Martin Thomson 3382 Microsoft 3383 3210 Porter Drive 3384 Palo Alto, CA 94304 3385 US 3387 Phone: +1 650-353-1925 3388 Email: martin.thomson@skype.net 3390 James Winterbottom 3391 Unaffiliated 3392 AU 3394 Email: a.james.winterbottom@gmail.com