Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Hi Vincent,

I’ve taken a look at the –17. Thanks for accommodating many of my DISCUSS
points. I have a one response below on a couple of remaining issues.

On 8/21/14, 12:59 AM, "Vincent Chen" <[e-mail]> wrote:

> 
>> 
>> = Section 5.1 =
>> I'd like to discuss why the single point location format needs to be
>> supported here. Is it really the case that a portion of whitespace
>> spectrum will ever be available only at a single point, as opposed to a
>> region? If not, it seems like sending a point (and, moreover, allowing
>> region to be unsupported but not point) divulges more precise information
>> about the requesting device than is ever actually necessary to fulfill
>> the goals of this protocol. Do regulators require a single point? Why?
> 
> The resulting spectrum is valid for 100m (typically) radius around that point.
> 
> Computation of available spectrum for a region is actually complex and not
> well defined...
>  
>> 
>> = Section 5.2 =
>> I'd like to discuss why the device serial number needs to be included in
>> the device descriptor, rather than some (perhaps persistent) randomly
>> generated device identifier that is used only in the context of this
>> protocol (which would better protect the privacy of the user of the
>> device, since the whitespaces database administrator wouldn't be able to
>> correlate the device's spectrum requests with other activities linked to
>> the serial number). It's not really clear why serial number is collected
>> since both this document and RFC 6953 note the protocol does not defend
>> against abuse or mis-use of spectrum.
> 
> The regulator want to have the ability to black list ranges of serial numbers,
> if it
> determines that a series was defective. The Databases must use the serial
> number
> to determine it can return available spectrum.
>  
>> 
>> I'm asking the above two questions in light of requirement P.7 from RFC
>> 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of
>> device-provided data where such protection is feasible, allowed, and
>> desired."
>> 
>> A separate interesting question that does not seem to be addressed
>> anywhere in the draft is whether a device can be fingerprinted by the
>> database operator by virtue of the collection of elements it sends
>> (rulesetIds, manufacturer, model, antenna characteristics, device
>> capabilities, etc.) even if it doesn't send a serial number or device
>> owner information that uniquely identify it. That seems worth discussion
>> in Section 10.
> 
> What should the discussion say? Just that it is possible? or does it need
> to have a solution?

Now that the document is clear that Slave device location and serial number
are optional (unless required by a ruleset), I think the remaining task on
the above three points is to add a bit of text to Section 10 to explain the
potential privacy threats from authorized databases, perhaps as a short
paragraph or two at the end of Section 10. Something along these lines (just
a suggestion, feel free to reject this entirely or use bits that you like):

"In addition to the privacy risks described above, in some cases, users of
Master or Slave devices may open themselves up to privacy risks related to
the secondary use of PAWS-related information by a database administrator.
For example, in situations where rulesets require that Master or Slave
devices uniquely identify themselves (via the DeviceDescriptor or
DeviceOwner parameters), database administrators may be able to use that
information to track connectivity activity over time, or they may share such
tracking information with third parties. Where Master or Slave devices
choose to provide or are required to provide geolocation information in
conjunction with unique device identifiers, this capability may further
extent to location tracking. Even where a device does not provide a specific
unique identifier, a database administrator may be able to uniquely
fingerprint a device based on the combination of other information provided
in DeviceDescriptor or DeviceCapabilities parameters.

In cases where devices have a choice to not send device-identifying
information or geolocation, or to send less granular geolocation (i.e., a
region rather than a point), PAWS implementations can reduce the risks
associated with secondary use by not sending that information. Where
rulesets require this information to be sent, these risks require
out-of-band mitigation (e.g., public statements or contractual terms
preventing secondary use).”

Thanks,
Alissa

>  
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> = Shepherd write-up=
>> "An in-depth review by a JSON expert might be useful."
>> 
>> Did that happen?
> 
> Tim Bray had looked at it before final call.
>  
>> 
>> = Section 1 =
>> "It opens the door for innovations in spectrum
>>    management that can incorporate a variety of parameters, including
>>    user location and time.  In the future, it also can include other
>>    parameters, such as user priority, time, signal type and power,
>>    spectrum supply and demand, payment or micro-auction bidding, and
>>    more."
>> 
>> Time seems to be listed both as a current parameter and a future one,
>> which is confusing.
> 
> Agreed. The second "time" should be removed.
>  
>> 
>> = Section 4.4 =
>> "FCC rules, for example, require that a 'Fixed Device'
>>    register its owner and operator contact information, its device
>>    identifier, its location, and its antenna height."
>> 
>> It would be nice to have a citation for the rules referenced here.
> 
> OK.
>  
>> 
>> = Section 5.1 =
>> Feel free to ignore this if it's completely misguided, but does altitude
>> really not matter? Are we sure this protocol won't be re-used for devices
>> on airplanes trying to find available spectrum? (I note that in RFC 6953,
>> requirement D.1 specifies that the data model must support "the height
>> and its uncertainty" -- I have no idea what "the height" means or if it
>> is related to altitude.)
> 
> See Section 5.3 on "height" of the antenna. It's separated out, from the
> "latitude, longitude" specification
> of GeoLocation. It allows specification with respect to ground level or mean
> sea level, and is intended
> for Fixed devices, rather than mobile devices.
> 
> From the current regulator's perspective, the allowed power for mobile devices
> is low enough that
> height does not matter.
> 
>  
>> 
>> = Section 10 =
>> I agree with Stephen that the database operator should be considered as a
>> potential adversary from the standpoint of potentially being able to
>> create a fine-grained database that tracks the locations and spectrum use
>> patterns of individual devices. That data could certainly be abused.
>> 
> 
> So just listing that as a potential threat and declare that fixing this as out
> of scope is sufficient?
> 
> Or do we need to state that Databases MUST not track? I can see how anonymized
> tracking
> can be useful for spectrum management in the future, much like anonymized
> tracking of car locations
> provide valuable traffic information for navigation systems.
> 
> -- 
> -vince