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.

   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

   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.

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.

   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

   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.

   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

   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.

   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.

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.

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.

   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).

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.

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"/>

             <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

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

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>

     <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}:"/>

         <!-- 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

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>

     <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"/>

             <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