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

[Vincent Chen <[e-mail]>]

Hi Alissa,

Sorry for the delayed response. I've uploaded draft 18, incorporating your
suggestions. I've simplified the text a bit, but, hopefully, it addresses
your concerns. Please let me know what you think.

http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-18

Thanks.

-vince

On Fri, Sep 12, 2014 at 9:03 AM, Alissa Cooper <[e-mail]> wrote:

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


-- 
-vince