I think that's a different threat from the one addressed below in threat 6.
If in a regulatory domain the DB requires the master to provide its identity, then there's nothing to be done to prevent tracking of the masters by the DB. But if some other regulatory domain will not require the master to send its identity when querying the DB, the master may decide not to send its identity, to prevent the DB to track it. We could add this as another threat. - Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Stephen Farrell Sent: Thursday, February 02, 2012 12:49 PM To: Patil Basavaraj (Nokia-CIC/Dallas) Cc: [email protected] Subject: Re: [paws] Threat model (Rev 2) 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.) Why is it only location tracking that's of concern? Why is exposing identity not an equal deal? Same logic as above. S. _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
