Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7105

Using Device-Provided Location-Related Measurements in Location Configuration Protocols

Pages: 74
Proposed Standard
Errata
Part 3 of 4 – Pages 30 to 51
First   Prev   Next

Top   ToC   RFC7105 - Page 30   prevText

7. Security Considerations

The use of location-related measurement data has privacy considerations that are discussed in Section 6.

7.1. Threat Model

The threat model for location-related measurement data concentrates on the Device providing falsified, stolen, or incorrect measurement data.
Top   ToC   RFC7105 - Page 31
   A Device that provides location-related measurement data might use
   data to:

   o  acquire the location of another Device, without authorization;

   o  extract information about network topology; or

   o  coerce the LIS into providing falsified location information based
      on the measurement data.

   Location-related measurement data describes the physical environment
   or network attachment of a Device.  A third-party adversary in the
   proximity of the Device might be able to alter the physical
   environment such that the Device provides measurement data that is
   controlled by the third party.  This might be used to indirectly
   control the location information that is derived from measurement
   data.

7.1.1. Acquiring Location Information without Authorization

Requiring authorization for location requests is an important part of privacy protections of a location protocol. A location configuration protocol usually operates under a restricted policy that allows a requester to obtain their own location. HELD identity extensions [RFC6155] allow other entities to be authorized, conditional on a Rule Maker providing sufficient authorization. The intent of these protections is to ensure that a location recipient is authorized to acquire location information. Location- related measurement data could be used by an attacker to circumvent such authorization checks if the association between measurement data and Target Device is not validated by a LIS. A LIS can be coerced into providing location information for a Device that a location recipient is not authorized to receive. A request identifies one Device (implicitly or explicitly), but measurement data is provided for another Device. If the LIS does not check that the measurement data is for the identified Device, it could incorrectly authorize the request. By using unverified measurement data to generate a response, the LIS provides information about a Device without appropriate authorization. The feasibility of this attack depends on the availability of information that links a Device with measurement data. In some cases, measurement data that is correlated with a Target is readily available. For instance, LLDP measurements (Section 5.1) are
Top   ToC   RFC7105 - Page 32
   broadcast to all nodes on the same network segment.  An attacker on
   that network segment can easily gain measurement data that relates a
   Device with measurements.

   For some types of measurement data, it's necessary for an attacker to
   know the location of the Target in order to determine what
   measurements to use.  This attack is meaningless for types of
   measurement data that require that the attacker first know the
   location of the Target before measurement data can be acquired or
   fabricated.  GNSS measurements (Section 5.5) share this trait with
   many wireless location determination methods.

7.1.2. Extracting Network Topology Data

Allowing requests with measurements might be used to collect information about network topology. Network topology can be considered sensitive information by a network operator for commercial or security reasons. While it is impossible to completely prevent a Device from acquiring some knowledge of network topology if a location service is provided, a network operator might desire to limit how much of this information is made available. Mapping a network topology does not require that an attacker be able to associate measurement data with a particular Device. If a requester is able to try a number of measurements, it is possible to acquire information about network topology. It is not even necessary that the measurements are valid; random guesses are sufficient, provided that there is no penalty or cost associated with attempting to use the measurements.

7.1.3. Exposing Network Topology Data

A Device could reveal information about a network to entities outside of that network if it provides location measurement data to a LIS that is outside of that network. With the exception of GNSS measurements, the measurements in this document provide information about an access network that could reveal topology information to an unauthorized recipient. A Device MUST NOT provide information about network topology without a clear signal that the recipient is authorized. A LIS that is discovered using DHCP as described in LIS discovery [RFC5986] can be considered to be authorized to receive information about the access network.
Top   ToC   RFC7105 - Page 33

7.1.4. Lying by Proxy

Location information, which includes measurement data, is a function of its inputs. Thus, falsified measurement data can be used to alter the location information that is provided by a LIS. Some types of measurement data are relatively easy to falsify in a way that causes the resulting location information to be selected with little or no error. For instance, GNSS measurements are easy to use for this purpose because all the contextual information necessary to calculate a position using measurements is broadcast by the satellites [HARPER]. An attacker that falsifies measurement data gains little if they are the only recipient of the result. The attacker knows that the location information is bad. The attacker only gains if the information can somehow be attributed to the LIS by another location recipient. By coercing the LIS into providing falsified location information, any credibility that the LIS might have -- that the attacker does not -- is gained by the attacker. A third party that is reliant on the integrity of the location information might base an evaluation of the credibility of the information on the source of the information. If that third party is able to attribute location information to the LIS, then an attacker might gain. Location information that is provided to the Device without any means to identify the LIS as its source is not subject to this attack. The Device is identified as the source of the data when it distributes the location information to location recipients. Location information is attributed to the LIS either through the use of digital signatures or by having the location recipient directly interact with the LIS. A LIS that digitally signs location information becomes identifiable as the source of the data. Similarly, the LIS is identified as a source of data if a location recipient acquires information directly from a LIS using a location URI.

7.1.5. Measurement Replay

The values of some measured properties do not change over time for a single location. The time invariance of network properties is often a direct result of the practicalities of operating the network. Limiting the changes to a network ensures greater consistency of service. A largely static network also greatly simplifies the data management tasks involved with providing a location service.
Top   ToC   RFC7105 - Page 34
   However, time-invariant properties allow for simple replay attacks,
   where an attacker acquires measurements that can later be used
   without being detected as being invalid.

   Measurement data is frequently an observation of a time-invariant
   property of the environment at the subject location.  For
   measurements of this nature, nothing in the measurement itself is
   sufficient proof that the Device is present at the resulting
   location.  Measurement data might have been previously acquired and
   reused.

   For instance, the identity of a radio transmitter, if broadcast by
   that transmitter, can be collected and stored.  An attacker that
   wishes it known that they exist at a particular location can claim to
   observe this transmitter at any time.  Nothing inherent in the claim
   reveals it to be false.

7.1.6. Environment Spoofing

Some types of measurement data can be altered or influenced by a third party so that a Device unwittingly provides falsified data. If it is possible for a third party to alter the measured phenomenon, then any location information that is derived from this data can be indirectly influenced. Altering the environment in this fashion might not require involvement with either a Device or LIS. Measurement that is passive -- where the Device observes a signal or other phenomenon without direct interaction -- is most susceptible to alteration by third parties. Measurement of radio signal characteristics is especially vulnerable, since an adversary need only be in the general vicinity of the Device and be able to transmit a signal. For instance, a GNSS spoofer is able to produce fake signals that claim to be transmitted by any satellite or set of satellites (see [GPS.SPOOF]). Measurements that require direct interaction increase the complexity of the attack. For measurements relating to the communication medium, a third party cannot avoid direct interaction; they need only be on the communications path (that is, man in the middle). Even if the entity that is interacted with is authenticated, this does not provide any assurance about the integrity of measurement data. For instance, the Device might authenticate the identity of a radio transmitter through the use of cryptographic means and obtain signal strength measurements for that transmitter. Radio signal
Top   ToC   RFC7105 - Page 35
   strength is trivial for an attacker to increase simply by receiving
   and amplifying the raw signal; it is not necessary for the attacker
   to be able to understand the signal content.

      Note: This particular "attack" is more often completely
      legitimate.  Radio repeaters are a commonplace mechanism used to
      increase radio coverage.

   Attacks that rely on altering the observed environment of a Device
   require countermeasures that affect the measurement process.  For
   radio signals, countermeasures could include the use of authenticated
   signals, or altered receiver design.  In general, countermeasures are
   highly specific to the individual measurement process.  An exhaustive
   discussion of these issues is left to the relevant literature for
   each measurement technology.

   A Device that provides measurement data is assumed to be responsible
   for applying appropriate countermeasures against this type of attack.

   Where a Device is the sole recipient of location information derived
   from measurement data, a LIS might choose to provide location
   information without any validation.  The responsibility for ensuring
   the veracity of the measurement data lies with the Device.

   Measurement data that is susceptible to this sort of influence SHOULD
   be treated as though it were produced by an untrusted Device for
   those cases where a location recipient might attribute the location
   information to the LIS.  GNSS measurements and radio signal strength
   measurements can be affected relatively cheaply, though almost all
   other measurement types can be affected with varying costs to an
   attacker, with the largest cost often being a requirement for
   physical access.  To the extent that it is feasible, measurement data
   SHOULD be subjected to the same validation as for other types of
   attacks that rely on measurement falsification.

      Note: Altered measurement data might be provided by a Device that
      has no knowledge of the alteration.  Thus, an otherwise trusted
      Device might still be an unreliable source of measurement data.

7.2. Mitigation

The following measures can be applied to limit or prevent attacks. The effectiveness of each depends on the type of measurement data and how that measurement data is acquired.
Top   ToC   RFC7105 - Page 36
   Two general approaches are identified for dealing with untrusted
   measurement data:

   1.  Require independent validation of measurement data or the
       location information that is produced.

   2.  Identify the types of sources that provided the measurement data
       from which that location information was derived.

   This section goes into more detail on the different forms of
   validation in Sections 7.2.1, 7.2.2, and 7.2.3.  The impact of
   attributing location information to sources is discussed in more
   detail in Section 7.2.4.

   Any costs in validation are balanced against the degree of integrity
   desired from the resulting location information.

7.2.1. Measurement Validation

Recognizing that measurement data has been falsified is difficult in the absence of integrity mechanisms. Independent confirmation of the veracity of measurement data ensures that the measurement is accurate and that it applies to the correct Device. When it's possible to gather the same measurement data from a trusted and independent source without undue expense, the LIS can use the trusted data in place of what the untrusted Device has sent. In cases where that is impractical, the untrusted data can provide hints that allow corroboration of the data (see Section 7.2.1.1). Measurement information might not contain any inherent indication that it is falsified. In addition, it can be difficult to obtain information that would provide any degree of assurance that the measurement device is physically at any particular location. Measurements that are difficult to verify require other forms of assurance before they can be used.
7.2.1.1. Effectiveness
Measurement validation MUST be used if measurement data for a particular Device can be easily acquired by unauthorized location recipients, as described in Section 7.1.1. This prevents unauthorized access to location information using measurement data. Validation of measurement data can be significantly more effective than independent acquisition of the same. For instance, a Device in a large Ethernet network could provide a measurement indicating its point of attachment using LLDP measurements. For a LIS, acquiring
Top   ToC   RFC7105 - Page 37
   the same measurement data might require a request to all switches in
   that network.  With the measurement data, validation can target the
   identified switch with a specific query.

   Validation is effective in identifying falsified measurement data
   (Section 7.1.4), including attacks involving replay of measurement
   data (Section 7.1.5).  Validation also limits the amount of network
   topology information (Section 7.1.2) made available to Devices to
   that portion of the network topology to which they are directly
   attached.

   Measurement validation has no effect if the underlying environment is
   being altered (Section 7.1.6).

7.2.1.2. Limitations (Unique Observer)
A Device is often in a unique position to make a measurement. It alone occupies the point in space-time that the location determination process seeks to determine. The Device becomes a unique observer for a particular property. The ability of the Device to become a unique observer makes the Device invaluable to the location determination process. As a unique observer, it also makes the claims of a Device difficult to validate and easy to spoof. As long as no other entity is capable of making the same measurements, there is also no other entity that can independently check that the measurements are correct and applicable to the Device. A LIS might be unable to validate all or part of the measurement data it receives from a unique observer. For instance, a signal strength measurement of the signal from a radio tower cannot be validated directly. Some portion of the measurement data might still be independently verified, even if all information cannot. In the previous example, the radio tower might be able to provide verification that the Device is present if it is able to observe a radio signal sent by the Device. If measurement data can only be partially validated, the extent to which it can be validated determines the effectiveness of validation against these attacks.
Top   ToC   RFC7105 - Page 38
   The advantage of having the Device as a unique observer is that it
   makes it difficult for an attacker to acquire measurements without
   the assistance of the Device.  Attempts to use measurements to gain
   unauthorized access to measurement data (Section 7.1.1) are largely
   ineffectual against a unique observer.

7.2.2. Location Validation

Location information that is derived from location-related measurement data can also be verified against trusted location information. Rather than validating inputs to the location determination process, suspect locations are identified at the output of the process. Trusted location information is acquired using sources of measurement data that are trusted. Untrusted location information is acquired using measurement data provided from untrusted sources, which might include the Device. These two locations are compared. If the untrusted location agrees with the trusted location, the untrusted location information is used. Algorithms for the comparison of location information are not included in this document. However, a simple comparison for agreement might require that the untrusted location be entirely contained within the uncertainty region of the trusted location. There is little point in using a less accurate, less trusted location. Untrusted location information that has worse accuracy than trusted information can be immediately discarded. There are multiple factors that affect accuracy, uncertainty and currency being the most important. How location information is compared for accuracy is not defined in this document.
7.2.2.1. Effectiveness
Location validation limits the extent to which falsified -- or erroneous -- measurement data can cause an incorrect location to be reported. Location validation can be more efficient than validation of inputs, particularly for a unique observer (Section 7.2.1.2). Validating location ensures that the Device is at or near the resulting location. Location validation can be used to limit or prevent all of the attacks identified in this document.
Top   ToC   RFC7105 - Page 39
7.2.2.2. Limitations
The trusted location that is used for validation is always less accurate than the location that is being checked. The amount by which the untrusted location is more accurate, is the same amount that an attacker can exploit. For example, a trusted location might indicate an uncertainty region with a radius of five kilometers. An untrusted location that describes a 100-meter uncertainty within the larger region might be accepted as more accurate. An attacker might still falsify measurement data to select any location within the larger uncertainty region. While the 100-meter uncertainty that is reported seems more accurate, a falsified location could be anywhere in the five-kilometer region. Where measurement data might have been falsified, the actual uncertainty is effectively much higher. Local policy might allow differing degrees of trust to location information derived from untrusted measurement data. This might be a boolean operation with only two possible outcomes: untrusted location information might be used entirely or not at all. Alternatively, untrusted location information could be combined with trusted location information using different weightings, based on a value set in local policy.

7.2.3. Supporting Observations

Replay attacks using previously acquired measurement data are particularly hard to detect without independent validation. Rather than validate the measurement data directly, supplementary data might be used to validate measurements or the location information derived from those measurements. These supporting observations could be used to convey information that provides additional assurance that measurement data from the Device was acquired at a specific time and place. In effect, the Device is requested to provide proof of its presence at the resulting location. For instance, a Device that measures attributes of a radio signal could also be asked to provide a sample of the measured radio signal. If the LIS is able to observe the same signal, the two observations could be compared. Providing that the signal cannot be predicted in advance by the Device, this could be used to support the claim that the Device is able to receive the signal. Thus, the Device is likely to be within the range that the signal is transmitted. A LIS could use this to attribute a higher level of trust in the associated measurement data or resulting location.
Top   ToC   RFC7105 - Page 40
7.2.3.1. Effectiveness
The use of supporting observations is limited by the ability of the LIS to acquire and validate these observations. The advantage of selecting observations independent of measurement data is that observations can be selected based on how readily available the data is for both LIS and Device. The amount and quality of the data can be selected based on the degree of assurance that is desired. The use of supporting observations is similar to both measurement validation and location validation. All three methods rely on independent validation of one or more properties. The applicability of each method is similar. The use of supporting observations can be used to limit or prevent all of the attacks identified in this document.
7.2.3.2. Limitations
The effectiveness of the validation method depends on the quality of the supporting observation: how hard it is for the entity performing the validation to obtain the data at a different time or place, how difficult it is to guess, and what other costs might be involved in acquiring this data. In the example of an observed radio signal, requesting a sample of the signal only provides an assurance that the Device is able to receive the signal transmitted by the measured radio transmitter. This only provides some assurance that the Device is within range of the transmitter. As with location validation, a Device might still be able to provide falsified measurements that could alter the value of the location information as long as the result is within this region. Requesting additional supporting observations can reduce the size of the region over which location information can be altered by an attacker, or increase trust in the result, but each additional measurement imposes an acquisition cost. Supporting observations contribute little or nothing toward the primary goal of determining the location of the Device.

7.2.4. Attribution

Lying by proxy (Section 7.1.4) relies on the location recipient being able to attribute location information to a LIS. The effectiveness of this attack is negated if location information is explicitly attributed to a particular source.
Top   ToC   RFC7105 - Page 41
   This requires an extension to the location object that explicitly
   identifies the source (or sources) of each item of location
   information.

   Rather than relying on a process that seeks to ensure that location
   information is accurate, this approach instead provides a location
   recipient with the information necessary to reach their own
   conclusion about the trustworthiness of the location information.

   Including an authenticated identity for all sources of measurement
   data presents a number of technical and operational challenges.  It
   is possible that the LIS has a transient relationship with a Device.
   A Device is not expected to share authentication information with a
   LIS.  There is no assurance that Device identification is usable by a
   potential location recipient.  Privacy concerns might also prevent
   the sharing of identification information, even if it were available
   and usable.

   Identifying the type of measurement source allows a location
   recipient to make a decision about the trustworthiness of location
   information without depending on having authenticated identity
   information for each source.  An element for this purpose is defined
   in Section 4.4.

   When including location information that is based on measurement data
   from sources that might be untrusted, a LIS SHOULD include
   alternative location information that is derived from trusted sources
   of measurement data.  Each item of location information can then be
   labeled with the source of that data.

   A location recipient that is able to identify a specific source of
   measurement data (whether it be LIS or Device) can use this
   information to attribute location information to either entity or to
   both entities.  The location recipient is then better able to make
   decisions about trustworthiness based on the source of the data.

   A location recipient that does not understand the "source" element is
   unable to make this distinction.  When constructing a PIDF-LO
   document, trusted location information MUST be placed in the PIDF-LO
   so that it is given higher priority to any untrusted location
   information according to Rule #8 of [RFC5491].

   Attribution of information does nothing to address attacks that alter
   the observed parameters that are used in location determination
   (Section 7.1.6).
Top   ToC   RFC7105 - Page 42

7.2.5. Stateful Correlation of Location Requests

Stateful examination of requests can be used to prevent a Device from attempting to map network topology using requests for location information (Section 7.1.2). Simply limiting the rate of requests from a single Device reduces the amount of data that a Device can acquire about network topology. A LIS could also make observations about the movements of a Device. A Device that is attempting to gather topology information is likely to be assigned a location that changes significantly between subsequent requests, possibly violating physical laws (or lower limits that might still be unlikely) with respect to speed and acceleration.

7.3. An Unauthorized or Compromised LIS

A compromised LIS, or a compromise in LIS discovery [RFC5986], could lead to an unauthorized entity obtaining measurement data. This information could then be used or redistributed. A Device MUST ensure that it authenticates a LIS, as described in Section 9 of [RFC5985]. An entity that is able to acquire measurement data can, in addition to using those measurements to learn the location of a Device, also use that information for other purposes. This information can be used to provide insight into network topology (Section 7.1.2). Measurement data might also be exploited in other ways. For example, revealing the type of 802.11 transceiver that a Device uses could allow an attacker to use specific vulnerabilities to attack a Device. Similarly, revealing information about network elements could enable targeted attacks on that infrastructure.

8. Measurement Schemas

The schemas are broken up into their respective functions. A base container schema into which all measurements are placed is defined, including the definition of a measurement request (Section 8.1). A PIDF-LO extension is defined in a separate schema (Section 8.2). A basic Types Schema contains common definitions, including the "rmsError" and "samples" attributes, plus types for IPv4, IPv6, and MAC addresses (Section 8.3). Each of the specific measurement types is defined in a separate schema.
Top   ToC   RFC7105 - Page 43

8.1. Measurement Container Schema

<?xml version="1.0"?> <xs:schema xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:geopriv:lm"> </xs:appinfo> <xs:documentation source="http://www.rfc-editor.org/rfc/rfc7105.txt"> This schema defines a framework for location measurements. </xs:documentation> </xs:annotation> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:element name="measurements"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="time" type="xs:dateTime"/> <xs:attribute name="timeError" type="bt:positiveDouble"/> <xs:attribute name="expires" type="xs:dateTime"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="measurementRequest" type="lm:measurementRequestType"/> <xs:complexType name="measurementRequestType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element ref="lm:measurement" minOccurs="0" maxOccurs="unbounded"/>
Top   ToC   RFC7105 - Page 44
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="measurement" type="lm:measurementType"/>
     <xs:complexType name="measurementType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="type" type="xs:QName" use="required"/>
           <xs:attribute name="samples" type="xs:positiveInteger"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <!-- PIDF-LO extension for source -->
     <xs:element name="source" type="lm:sourceType"/>
     <xs:simpleType name="sourceType">
       <xs:list>
         <xs:simpleType>
           <xs:restriction base="xs:token">
             <xs:enumeration value="lis"/>
             <xs:enumeration value="device"/>
             <xs:enumeration value="other"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:list>
     </xs:simpleType>
   </xs:schema>

                       Measurement Container Schema
Top   ToC   RFC7105 - Page 45

8.2. Measurement Source Schema

<?xml version="1.0"?> <xs:schema xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc"> </xs:appinfo> <xs:documentation source="http://www.rfc-editor.org/rfc/rfc7105.txt"> This schema defines an extension to PIDF-LO that indicates the type of measurement source that produced the measurement data used in generating the associated location information. </xs:documentation> </xs:annotation> <xs:element name="source" type="lmsrc:sourceType"/> <xs:simpleType name="sourceType"> <xs:list> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="lis"/> <xs:enumeration value="device"/> <xs:enumeration value="other"/> </xs:restriction> </xs:simpleType> </xs:list> </xs:simpleType> </xs:schema> Measurement Source PIDF-LO Extension Schema
Top   ToC   RFC7105 - Page 46

8.3. Base Types Schema

Note that the pattern rules in the following schema wrap due to length constraints. None of the patterns contain whitespace. <?xml version="1.0"?> <xs:schema xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:geopriv:lm:basetypes"> </xs:appinfo> <xs:documentation source="http://www.rfc-editor.org/rfc/rfc7105.txt"> This schema defines a set of base type elements. </xs:documentation> </xs:annotation> <xs:simpleType name="byteType"> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="255"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="twoByteType"> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="65535"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="nonNegativeDouble"> <xs:restriction base="xs:double"> <xs:minInclusive value="0.0"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="positiveDouble"> <xs:restriction base="bt:nonNegativeDouble"> <xs:minExclusive value="0.0"/> </xs:restriction> </xs:simpleType>
Top   ToC   RFC7105 - Page 47
     <xs:complexType name="doubleWithRMSError">
       <xs:simpleContent>
         <xs:extension base="xs:double">
           <xs:attribute name="rmsError" type="bt:positiveDouble"/>
           <xs:attribute name="samples" type="xs:positiveInteger"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
     <xs:complexType name="nnDoubleWithRMSError">
       <xs:simpleContent>
         <xs:restriction base="bt:doubleWithRMSError">
           <xs:minInclusive value="0"/>
         </xs:restriction>
       </xs:simpleContent>
     </xs:complexType>

     <xs:simpleType name="ipAddressType">
       <xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
     </xs:simpleType>

     <!-- IPv6 format definition -->
     <xs:simpleType name="IPv6AddressType">
       <xs:annotation>
         <xs:documentation>
             An IP version 6 address, based on RFC 4291.
         </xs:documentation>
       </xs:annotation>
       <xs:restriction base="xs:token">
         <!-- Fully specified address -->
         <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
         <!-- Double colon start -->
         <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
         <!-- Double colon middle -->
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
                            (:[0-9A-Fa-f]{1,4}){1}"/>
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
                            (:[0-9A-Fa-f]{1,4}){1,2}"/>
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
                            (:[0-9A-Fa-f]{1,4}){1,3}"/>
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
                            (:[0-9A-Fa-f]{1,4}){1,4}"/>
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
                            (:[0-9A-Fa-f]{1,4}){1,5}"/>
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
                            (:[0-9A-Fa-f]{1,4}){1,6}"/>
         <!-- Double colon end -->
         <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
Top   ToC   RFC7105 - Page 48
         <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
         <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
             (:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
             (:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
             |((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
             [0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
             ?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
             [0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
             [0-9]?[0-9])"/>
         <!-- The unspecified address -->
         <xs:pattern value="::"/>
       </xs:restriction>
     </xs:simpleType>

     <!-- IPv4 format definition -->
     <xs:simpleType name="IPv4AddressType">
       <xs:restriction base="xs:token">
         <xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                            (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                            (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                            (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
       </xs:restriction>
     </xs:simpleType>

     <!-- MAC address (EUI-48) or EUI-64 address -->
     <xs:simpleType name="macAddressType">
       <xs:restriction base="xs:token">
         <xs:pattern
     value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
       </xs:restriction>
     </xs:simpleType>
   </xs:schema>

                             Base Types Schema
Top   ToC   RFC7105 - Page 49

8.4. LLDP Measurement Schema

<?xml version="1.0"?> <xs:schema xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:geopriv:lm:lldp"> </xs:appinfo> <xs:documentation source="http://www.rfc-editor.org/rfc/rfc7105.txt"> This schema defines a set of LLDP location measurements. </xs:documentation> </xs:annotation> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:element name="lldp" type="lldp:lldpMeasurementType"/> <xs:complexType name="lldpMeasurementType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="chassis" type="lldp:lldpDataType"/> <xs:element name="port" type="lldp:lldpDataType"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="lldpDataType"> <xs:simpleContent> <xs:extension base="lldp:lldpOctetStringType"> <xs:attribute name="type" type="bt:byteType" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType>
Top   ToC   RFC7105 - Page 50
     <xs:simpleType name="lldpOctetStringType">
       <xs:restriction base="xs:hexBinary">
         <xs:minLength value="1"/>
         <xs:maxLength value="255"/>
       </xs:restriction>
     </xs:simpleType>
   </xs:schema>

                          LLDP Measurement Schema

8.5. DHCP Measurement Schema

<?xml version="1.0"?> <xs:schema xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:geopriv:lm:dhcp"> </xs:appinfo> <xs:documentation source="http://www.rfc-editor.org/rfc/rfc7105.txt"> This schema defines a set of DHCP location measurements. </xs:documentation> </xs:annotation> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <!-- DHCP Relay Agent Information option --> <xs:element name="dhcp-rai" type="dhcp:dhcpType"/> <xs:complexType name="dhcpType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="giaddr" type="bt:ipAddressType"/> <xs:element name="circuit" type="xs:hexBinary" minOccurs="0"/> <xs:element name="remote" type="dhcp:dhcpRemoteType" minOccurs="0"/> <xs:element name="subscriber" type="xs:hexBinary" minOccurs="0"/>
Top   ToC   RFC7105 - Page 51
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="dhcpRemoteType">
       <xs:simpleContent>
         <xs:extension base="xs:hexBinary">
           <xs:attribute name="enterprise" type="xs:positiveInteger"
                         use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
   </xs:schema>

                          DHCP Measurement Schema



(page 51 continued on part 4)

Next Section