Hi, On 2 Feb 2012, at 20:53, <[email protected]> wrote:
> > > On 2/2/12 2:48 PM, "ext Stephen Farrell" <[email protected]> wrote: > >> >> Pretty good overall. I'll keep on my usual track since I seem >> stuck on it here;-) >> >> On 02/02/2012 08:37 PM, [email protected] wrote: >>> >>> Threat 6: Third party tracking of white space device location >>> >>> >>> A master device needs to provide its location to the white >>> space database in order to obtain the channel availability >>> information at that location. Such location information can be >>> gleaned by an eavesdropper. A master device may prefer to keep >>> the location information secret. Hence the protocol should >>> provide a means to protect the location information and prevent >>> tracking of locations associated with a white space database. >> >> What's wrong with not wanting the DB to track me (as a master >> device)? Could be that current known regulators don't like >> anonymous masters, but that may change. (So I think 3rd party >> here is wrong.) > > The issue is not with the database tracking your location. It is a a > malicious node which could be eavesdropping on the link between the master > device and the database. The database will always have the master device's > location. Whether it saves that location is an orthogonal issue, but its > not the one that is captured in this threat. > >> >> Why is it only location tracking that's of concern? Why is >> exposing identity not an equal deal? Same logic as above. > > The concern is not about exposing location of identity to the white space > database. It seems like you're maybe conflating location and identity above, not sure. But those are different and will need to be differentiated in the protocol, and hence also in the requirements, S > > -Raj > > >> >> >> S. >> > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
