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

[Vincent Chen <[e-mail]>]

Thanks, Alissa!

The new sentence looks good and strikes a great balance. I'll add and
upload a new version.

-vince

On Wed, Sep 24, 2014 at 2:05 PM, Pete Resnick <[e-mail]>
wrote:

>  It sounds like we're closing in. Just in case, I've put the document on
> tomorrow's informal IESG telechat and invited Vince to join us (neither of
> the chairs can make it). If it resolves before then, great. If not, we'll
> work it out in real time.
>
> Thanks for working on this, all.
>
> pr
>
>
> On 9/24/14 3:28 PM, Alissa Cooper wrote:
>
> On 9/24/14, 6:17 AM, "Brian Rosen" <[e-mail]> wrote:
>
>   On the location issue, this is well traveled ground.
>
>  In many cases, the location of the device is no where near a boundary,
> and thus can be relatively imprecise.  As you get closer to a boundary, you
> need more precision in order to know if which side of the boundary you are
> on.  In white space, sometimes the regulator specifies the required
> accuracy of location, sometimes it doesn’t.
>
>  If you think about a canonical wireless microphone, you want location
> down to maybe 100 meters to avoid having problems with the microphone, but
> allow use of the spectrum where there is no problem of interference.  I
> wouldn’t want us to specify some default accuracy, but it really does need
> to be fairly accurate given current technology.  We’re starting to see
> location determination systems that could give us less than 2 meter
> accuracy in some environments, and that’s probably beyond what we need.
>
>  So you both are right.  Where the regulator specifies accuracy, that’s
> it, you send that, you need not send more.
> When the regulator doesn’t specify, someone has to put out a spec, and the
> clients need not send more accurate location.
>
>
>  Maybe we can build off of this and the text that Vince added in the –18
> to make one additional recommendation, at the end of the new paragraph in
> Section 10:
>
>  “Similarly, regulators should require, and implementations should
> provide, device location at a level of granularity only as precise as
> necessary to support accurate database responses.”
>
>  Or something like that.
>
>  Re-reading the new text, I agree that the fingerprinting bit is covered.
>
>  Alissa
>
>
>  But, we’ve also looked at obfuscation when you want to report location
> less precise than what you have.  What we know is that it’s really, really
> hard to do it.
>
>  Brian
>
>   On Sep 24, 2014, at 2:57 AM, Vincent Chen <[e-mail]> wrote:
>
>  Hi Alissa,
>
> On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[e-mail]> wrote:
>
>>  Hi Vince,
>>
>>  Thanks. I like the text you added, but I think the bit about
>> fingerprinting and the caution to implementations about not over-sharing
>> that I had suggested are both important — any reason not to include them
>> explicitly?
>>
>
>  Sorry I did not respond directly to these points. Here's my train of
> thought.
>
>  1. The whole point of the White Space Database is to give information
> about available spectrum at a location. The location has to be precise
> enough for the information to be valid. So it seems odd for PAWS to
> recommend that a device give imprecise location.
>
>  2. While PAWS does indicate that serial number is optional, it is
> unlikely that a regulator will make it optional.
>
>  In any cases I felt the statements indicating risk of tracking covers
> tracking via explicit information provided by the device and via implicit
> information derived from fingerprinting.
>
>  -vince
>
>
>
>>
>>
>>>  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
>>
>>
>
>
>  --
> -vince
>
>
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
>
>


-- 
-vince