Friday, July 29, 2011

[Geopriv] RFC 6225 on Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information

A new Request for Comments is now available in online RFC libraries.


RFC 6225

Title: Dynamic Host Configuration Protocol Options
for Coordinate-Based Location Configuration
Information
Author: J. Polk, M. Linsner,
M. Thomson, B. Aboba, Ed.
Status: Standards Track
Stream: IETF
Date: July 2011
Mailbox: jmpolk@cisco.com,
marc.linsner@cisco.com,
martin.thomson@andrew.com,
bernard_aboba@hotmail.com
Pages: 36
Characters: 77001
Obsoletes: RFC3825

I-D Tag: draft-ietf-geopriv-rfc3825bis-17.txt

URL: http://www.rfc-editor.org/rfc/rfc6225.txt

This document specifies Dynamic Host Configuration Protocol options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values. This document obsoletes RFC 3825.
[STANDARDS-TRACK]

This document is a product of the Geographic Location/Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Wednesday, July 27, 2011

[Geopriv] GEOPRIV minutes for IETF 81

----------
Minutes - GEOPRIV - IETF81

Summary (prepared by Richard Barnes):

1. Chairs' Introduction
The chairs noted the publication of RFC 6280 since the last IETF, and the entry of two other drafts into the RFC Editor queue. The residential gateway LIS discovery document needs reviews from people other than the authors.

2. Policy URIs
draft-ietf-geopriv-policy-uri
The document has been updated to address WGLC comments from Ted Hardie, Ben Campbell, and Adam Roach. The authors believe it is ready for publication request, and the chairs should submit soon.

3. HELD Measurement Extensions
draft-ietf-geopriv-held-measurements
The authors received a review from a Mozilla reviewer, and are awaiting one from a Skyhook reviewer. The draft will be revised based on this feedback. The chairs requested that the authors relay feedback they receive to the list.

4. Civic Address Extensibility
draft-ietf-geopriv-local-civic
The last remaining issue for this document was whether the IANA registry created by this document should have a single class and admission requirements, or whether it should be divided. After some discussion, there was consensus that the registry should be divided into two parts, one requiring standards action, and one with looser admission criteria (specificiation or FCFS). James Winterbottom agreed to make this change and re-submit the document.

5. GEOPRIV Policy
draft-ietf-geopriv-policy
Martin Thomson reviewed the single open issue with this draft, namely the question of what the document should say about obscuring of geodetic information. After some discussion, there was consensus that the authors would revise Mr. Thomson's draft text on this topic in order to clarify the risks associated with geodetic fuzzing (and making a rough analogy to civic fuzzing), and to move the example algorithm to an informative appendix.

Raw notes from Matt Lepinski follow.
--------

---------------
GEOPRIV
---------------

Note: Residential Gateway discovery needs reviewers who are not authors!

***** Policy URI (Richard Barnes)
-- Draft has completed working group last call (see slides for changes)
-- Draft publication will be requested soon

***** Local Civic (James Winterbottom)

-- Discussion of the registry created by the document
In particular, should the elements in this new registry have a flag indicating "SHOULD IMPLEMENT"
Cullen: Note that some IETF registries require a standards track document to get one of the 'primary' code points
but you can get a vendor-specific code point with a much lower requirement
James W: Note that if you don't implement a particular code point, there isn't any harm
(since we carry it through if you don't understand it)
Ted H: How does the 'SHOULD IMPLEMENT' affect the translation piece?
Paul H: We just tried to do this ('SHOULD IMPLEMENT' column in registry) in DNSext and the IESG said "No"
Brian R: Cites an example, when we created the fields in 4119 we added a 'suffix street type', it was mandatory to implement
... if we add a 'prefix street type' (Boulevard Coronado) in this registry it ought to be "SHOULD IMPLEMENT"
James W: I'm really struggling to see how the "SHOULD IMPLEMENT" flag helps us, if something is compliant with the current document
and it gets fields that it doesn't understand, it will still stick them in the PIDF-LO, so the ultimate consumer will
Brian R: We should have some way to bifurcate the registry (separate standards action entries from others)
James W: Is it enough to just put in a specification pointer in the registry?
Robert AD: You will get push-back from the IESG if you appear to be trying to make the IANA registry itself the specification.
Cullen: Just make two separate halfs of the registry, and we'll all be happy.
Anything that's different from how things are normally done makes the IETF unhappy.

-- Humm: Should the local Civic document define a registry with two parts (standards vs lesser bar)?
Chairs call concensus in the room in favor of spliting the registry into two parts, this will be confirmed on the list
(It appeared in the hum that only one or two people were humming "no" on this question)


***** Geopriv Policy : Location Obscuring (Martin Thompson)

-- Based on what I've read in the academic literature, I'm not sure that location obscuring
is a problem that we can every really solve, but we are going to try to it here anyway

Comment (missed name): What about new 'assumptions', does one continously have to design new algorithms?
Martin: Designing an algorithm that defeats a particular database, requires the algorithm have acces to that database
I don't think there's anything we can do about this
Cullen: You are making this sound much better than it really is. From an information-theoric point of view, we can't make this work.
Even just speed constraints on humans, make this Doomed
There is no algorithm that is going to work here for any meaningful set of constraints
Robert AD: We have agreed that any algorithm we were to select would have some form of suckage
However, I believe the community has told us that something a bit sucky is better than nothing at all
[do we have an IANA registry of algorithms with a column for 'degree of suckitude']
Martin: There was a suggestionf or a column of 'suckitude' in the IANA registry, but I don't think that is going to happen
Martin: I want to avoid making any statement about "how much" badness or leakage, the rule-maker makes the rules
Hannes T: It doesn't make sense to provide some 'lower bar' without knowing the application context
Martin: In essense we are starting a registry of encryption algorithms, and the only thing in the registry to begin with is ROT-13
Cullen: Agrees
Robert AD: Do you want to abandon this approach, Cullen, and instead put in text explaining that obfuscation doesn't work
Cullen: Ten years ago, I was would have said, we should never lie, there must be a better way. I no longer believe this
Note: It will be quite difficult to lie in such a way that the lies are believable
Cullen: If I only release the time-zone that I am in, you can corrolate this infromation and figure out what acquisitions that Cisco is looking at
Richard B: But there is some value in revealing only the city you are in.
There are use-cases for giving out city-level information in which users do not
Ted H: You can end up with a much worse situation with lying then we were to begin with.
(I could try to hide the identify of your mistress by lying and saying you are at the strip club)
What you are doing here is not suitable protection against an attack.
Instead, what you are doing is the equivalent to leaving civic elements out of a civic address.
No better and no worse. This is all you ever could do.

-- Appears to be general agreement with Ted.
Whenever you give out information about location, you are giving out information and there is a cost
(which we cannot prevent).
We are providing a way to disclose infromation at a given granularity, we are not protecting against any attack,
we are providing a mechanism for disclosing information based on user (rule-maker) preferences.

-- Question: Do we include an example algorithm with a discussion of why/how it sucks?

Cullen: If we don't put anything we're going to get multiple implementations which Take X and Y and add a random number to each
coordinate, with a new random number each time you call the function.
We should have an appendix with a non-normative algorithm that is better than the algorithm Cullen just described

Alissa Chair: If we include one that you might use, aren't people going to say "Why don't you include my algorithm too?"

Martin T: The problem that I have with this approach is how can the rule-maker convey his preferences in such a way that
he is reasonably certain that whatever algorithm is used will behaive in a way that meets the rule-maker's expectations

Jon P: There are really different threat models that you can differentaite ... there is a difference between Google and Facebook as the adversary
versus some pizza place that you order from twice in your life.
However, we can talk about threat models all we want,
but when the rule-maker decides what infromation to share, how can we expect him to make a reasonable judgement

Martin T: In all things Privacy, there is plenty of room for regrets

-- PLAN GOING FORWARD:
Martin and Ted will revise the document and put new text to the list within the next few weeks
(including an example algorithm and its suckitude in an appendix)
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, July 25, 2011

Re: [Geopriv] IETF 81 agenda

Dear GEOPRIV,

As a reminder, the GEOPRIV session for IETF 81 will begin immediately following after the half-length XMPP session, at around 10:15 tomorrow morning. The room is still the same, 206A.

In order to make the best use of our meeting time, could I ask for the following volunteers?
1. 2 note takers
2. 1 jabber scribe

Thanks,
--Richard

On Jul 25, 2011, at 10:03 AM, Alissa Cooper wrote:

> We have finalized the agenda now that the scheduling conflict with XMPP has been resolved:
>
> 5m Chairs intro & administrivia
> 10m draft-ietf-geopriv-policy-uri (R. Barnes)
> 10m draft-ietf-geopriv-held-measurements (M. Thomson)
> 10m draft-ietf-local-civic (J. Winterbottom)
> 30m draft-ietf-geopriv-policy (design team)
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] IETF 81 agenda

We have finalized the agenda now that the scheduling conflict with XMPP has been resolved:

5m Chairs intro & administrivia
10m draft-ietf-geopriv-policy-uri (R. Barnes)
10m draft-ietf-geopriv-held-measurements (M. Thomson)
10m draft-ietf-local-civic (J. Winterbottom)
30m draft-ietf-geopriv-policy (design team)
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Saturday, July 23, 2011

[Geopriv] BCP 160, RFC 6280 on An Architecture for Location and Location Privacy in Internet Applications

A new Request for Comments is now available in online RFC libraries.

BCP 160
RFC 6280

Title: An Architecture for Location and
Location Privacy in Internet Applications
Author: R. Barnes, M. Lepinski,
A. Cooper, J. Morris,
H. Tschofenig, H. Schulzrinne
Status: Best Current Practice
Stream: IETF
Date: July 2011
Mailbox: rbarnes@bbn.com,
mlepinski@bbn.com,
acooper@cdt.org, jmorris@cdt.org,
Hannes.Tschofenig@gmx.net, hgs@cs.columbia.edu
Pages: 41
Characters: 99801
Updates: RFC3693, RFC3694
See Also: BCP0160

I-D Tag: draft-ietf-geopriv-arch-03.txt

URL: http://www.rfc-editor.org/rfc/rfc6280.txt

Location-based services (such as navigation applications, emergency
services, and management of equipment in the field) need geographic
location information about Internet hosts, their users, and other
related entities. These applications need to securely gather and
transfer location information for location services, and at the same
time protect the privacy of the individuals involved. This document
describes an architecture for privacy-preserving location-based
services in the Internet, focusing on authorization, security, and
privacy requirements for the data formats and protocols used by these
services. This memo documents an Internet Best Current Practice.

This document is a product of the Geographic Location/Privacy Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Call for consensus on fuzzing text for geopriv-policy

On 2011-07-21 at 19:12:59, Hannes Tschofenig wrote:
> Hi Alissa, Hi Martin,
>
> your proposed algorithm assumes that there is a trigger point that is
> stored with each Target & location recipient.
> Jorge's algorithm did not make use of the same state requirement and
> instead had a grid pre-defined, as you known.
>
> You don't seem to like the grid-based approach. Any specific reason
> for not using the grid-based mechanism?
> We would then have an algorithm that is similar to what is currently
> in the document.

This is just the algorithm that I wrote up. A grid mechanism would be OK, it merely has a different set of problems - the most significant being the border-crossing problem.

> > .h3 Basic Assumptions
> >
> > A location recipient in possession of one or more reported locations
> > SHOULD have no more information about any known location without
> > making any assumptions about the nature of the known location.
> > That
> > is, an algorithm SHOULD NOT reveal any more information than its
> > inputs specify to an adversary that makes no assumptions.
>
> I am not sure how much these two paragraphs add. Everything succeeds
> and fails with the assumptions.

There are inherent properties of the algorithms that cause leakage - see the weakness below. Ideally, an algorithm doesn't have such weaknesses.

> For example, if a Target moves and the reported location changes
> (which it certainly has to at a certain point in time in any practical setup).
> This already tells the location recipient that the target is not
> stationary.

I don't think that's true. I can have two reported locations that correspond to the same known location. None of the algorithms proposed thus far do this, but nothing prevent this.

>
> >
> > .h2 Simple Obscuring Algorithm
> >
> > This algorithm takes a single distance in meters. It produces a
> > reported location with circular uncertainty area of that radius or
> > greater.
> >
> > As each known location is generated or received at the location
> > server:
> >
> > 1. Determine the distance between the centroid of the known location
> > to the trigger point. If there is no trigger point saved for this
> > target and location recipient, assume this distance is infinite.
>
> > If this distance is less than the input, do not report the location
> > and end the algorithm.
> >
>
> Here it needs to be ensured that in the stationary case the distance
> is always aways greater than the input since otherwise the location
> recipient does not get location reported anymore.
>
> > 2. Convert the known location to a circle
> > [I-D.thomson-geopriv-uncertainty].
>
> Is this a normative dependency?

It was supposed to be a "for example" reference. It can't be normative.

> >
> > 3. Set the trigger point to the centroid of the known location.
> >
>
>
> I believe it would be more clear to re-set the trigger point in step 4
> in case you end the algorithm since otherwise the re-setting it to the
> centroid of the known location makes no sense given that you re-set it
> again in a latter step.
> Something like:
>
> 4. If the known location has uncertainty equal to or greater than the
> input, report the known location, reset the trigger point to the
> centroid of the known location, and end the algorithm.

Unfortunately, if the next location has lower uncertainty, you reveal it at that point. So this doesn't work out very well.

> > 4. If the known location has uncertainty equal to or greater than
> > the input, report the known location and end the algorithm.
> >
> > 5. Select two uniformly distributed random numbers [RFC4086] between
> 0
> > and 1.
> >
> > 6. Set the centroid of the reported location by moving the centroid
> of
> > the known location randomly, using the two random numbers:
> >
> > - The distance is determined by taking the square root of the first
> > number and multiplying it by the difference between the input and
> > the uncertainty (radius) of the known location.
>
> >
> > - The angle (or heading) is determined by multiplying the second
> > number by 360 degrees (or 2*pi radians).
> >
> Could you explain your motivation for computing the distance and the
> angle in this specific fashion?

Certainly.

"This produces an offset that is evenly distributed over a circular area. This reduces the chance that an adversary can choose any particular point with a higher probability of being the known location."

>
> > 7. Set the uncertainty radius of the reported location to the input.
>
> If you do this wouldn't the system have location reports with a radius
> that equals the input value.
> For example, imagine that you have a system that uses GPS then the
> known location would have a fairly small uncertainty radius (almost
> always).
> Hence, almost all reported locations would have an uncertainty radius
> that corresponds to the input of the rule maker.

Correct. That means that your adversary learns the input very easily. The input is not a secret, as stated below.

> >
> > 8. Move the trigger point randomly by half the input using the
> process
> > used in Step 6 with a new pair of random numbers. Save the trigger
> > point for this target and location recipient.
> >
> > 9. Report the randomized location and end the algorithm.
> >
>
>
> Ciao
> Hannes
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Call for consensus on fuzzing text for geopriv-policy

Thanks Hannes.

I'll draft an update once we've had our discussion. For the most part, I've agreed with your comments.

On 2011-07-21 at 14:03:46, Hannes Tschofenig wrote:
> Hi Alissa, Hi Martin,
>
> On Jul 17, 2011, at 10:32 AM, Alissa Cooper wrote:
>
> > We'd like to get draft-ietf-geopriv-policy back to the IESG by the
> end of IETF 81.
> >
> > Upon request from the chairs, Martin Thomson has drafted the text
> below describing (1) the fuzzing algorithm evaluation criteria and (2)
> the performance of one algorithm against these criteria (a simple
> circle-based algorithm). We'd like to know if we have rough consensus
> to incorporate this text into the document so we can send it back to
> the IESG. Please express your opinion to the list by Friday, July 22
> (even if it's just, "yes, incorporate the text").
> >
> > Thanks,
> > Alissa
> >
> > ---------------
> >
> >
> > .h1 Location Obscuring Algorithm
> >
> > The purpose of a location obscuring algorithm is to provide a
> location
> > recipient (LR) with location information of reduced quality. The
> > intent is to provide an LR with location information that is
> > correct, but insufficient to identify the known location without a
> > chosen amount of uncertainty.
>
> ... but insufficient to determine the more precise location
> information as available to the location server, referred as 'known location'.

OK.

> >
> > The obscuring algorithm takes a series of _known locations_, which
> > might have greater accuracy than the recipient is permitted to
> > receive. The obscuring process produces a series of _reported
> > locations_.
> >
> > Location changes over time. A number of algorithms for obscuring
> > the location of stationary targets exist
> > [http://portal.acm.org/citation.cfm?id=1770566],
> >
> [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.1678&rep
> > =rep1&type=pdf], but are of questionable value when a target moves.
> >
>
> We don't do us a favor with such a text. We could argue with the
> authors of their proposal on why exactly we find them questionable but
> it does not help our document in any way.
> I would suggest to delete the paragraph. We then also do not have to
> add these new references.

Sure.

> > This section describes the goals for a location obscuring algorithm.
> > The normative "SHOULD" is used to describe goals, since it could be
> > impossible for any single algorithm to address all the described
> > goals. It is expected that some goals are only partially or
> > conditionally achieved by each algorithm.
>
> I would change this paragraph and also the beginning of the next
> section to:
> "
> .h2 Algorithm Goals
>
> This section lists design goals for location obscuring algorithms.
> The algorithm described in this document meets these goals and authors
> of yet-to-be-defined location obscuring algorithms are encouraged to
> consider these design goals as well.
> For convenience reasons we use RFC 2119 language to indicate the
> different levels of importance of the individual design goals.
> It could be impossible for any single algorithm to address all the
> describe goals and certain design goals may only be partially or
> conditionally achieved by a specific algorithm.
> "
>
> I am personally not a huge fan of normative statements about future
> algorithms because it almost sounds like the 'using protocol'
> requirements to me. Often the environment and technology changes and
> so the requirements then tend to be out of sync with what we have written.
> We say that with the using protocol requirements quite nicely and you
> had also objected to some of those. They also looked great at the time
> of writing...

That was the point that I was trying to get to with the "SHOULD" thing. At this stage, we're really just describing a wish-list. Normative language is possibly totally inappropriate in that context.

> > .h2 Algorithm Structure
> >
> > The algorithm SHOULD accept known locations with uncertainty and
> > produce reported locations with uncertainty that encloses the known
> > location at that time. That is, the reported location is no less
> > correct than the known location.
> >
> > An obscuring algorithm MUST include a description of the user-
> selected
> > inputs it uses and how those inputs affect output of the algorithm.
> >
> > Usability is an important consideration in selecting which inputs an
> > algorithm uses. A rule maker (RM) needs to be able to quickly and
> > easily comprehend the impact of a choosing any available option.
> >
> > This document describes a single input parameter: a distance in
> > meters. Algorithms that use this parameter ensure that there is at
> > least this much uncertainty in the reported location. Algorithms
> > SHOULD restrict their inputs to this one parameter to aid usability.
> >
> > .h2 Algorithm Assessment
> >
> > The effectiveness of an obscuring algorithm under all circumstances
> > might be imperfect. An assessment of effectiveness helps a rule
> maker
> > decide if an algorithm is appropriate.
>
> ... is appropriate for a specific application usage, context, and
> deployment environment.

Done.

> > An algorithm is measured against its goals. An algorithm that aims
> to
> > convey a chosen amount of uncertainty is only partially effective if
> > there are conditions where a location recipient is able to recover
> > location with less uncertainty. Determining the frequency or
> > probability of these conditions and the degree to which uncertainty
> is
> > reduced is the goal of an assessment.
> >
> > Assessment of an algorithm MUST assume that the location recipient
> > knows the choices made by the rule maker, which includes the details
> > of the algorithm and the selected inputs.
>
> I am not sure I capture the essence of the sentences. Are you trying
> to say that transparency is an important property in the design and
> all parties must have access to the algorithm description so that they
> can make (maybe via a third party) an assessment of the quality of the
> algorithm. If that's the idea I am fully on board with it.
> Transparency is important. (The same holds true for security
> algorithms as well.)

Kerckhoff's Principle. Yes.

> > This section describes one possible framework that aids in assessing
> > algorithms.
> >
> > The goal of the adversary or attacker is to derive information about
> > the known location from the reported location.
> >
> > In order to recover location, an adversary makes assumptions
> > [Duckham05] about the location of the target.
> The adversary makes assumptions about which location. It would only
> see the reported location but most likely the assumptions apply to the
> known location.

Correct. Though I wanted to imply that it's more than the known location that they make assumptions about - it's the "real" location.

> With assumption you are most likely referring to things like that the
> target follows certain landmarks, or so. Right? An example of the type
> of assumptions you have in mind would be useful.

That can be done. "By assuming that the target is on or near a road, the recipient can reduce uncertainty to the area near or around roads."

> I am also not quite sure about the value of the reference. While I had
> read the paper a while ago I am not sure from reading the sentence of
> what specifically you are making the reference to it for.

The reference provides a better description of this. The only real benefit of my crude summary is that it's short.

> > These assumptions are
> > applied to the reported location to produce a recovered location
> > that has lower uncertainty than the reported location.
> >
> > recovered = apply(reported, assumption)
> >
> > where:
> >
> > uncertainty(recovered) <= uncertainty(reported)
> > confidence(recovered) <= confidence(reported)
> >
>
> This sounds nice (for a paper) but in fact it does not add a lot for
> the rest of the writeup. Maybe we could shorten this text by omitting
> that part.

Let's drop it then. It was marginal anyway.

> > The assumptions that a recipient is forced to make to recover
> > information determines how effective an algorithm is.
>
> Wouldn't you also, like in security, consider the amount of reported
> location samples the adversary collected or the computational effort
> he has to make?
> Of course you could call this an "assumption"....

In terms of computation effort, I think that you need to assume that the adversary has considerable, though not infinite computational capacity. On the number of samples, it would be better to assume that the adversary has access to all previous samples and potentially all future samples.

> > An assumption
> > that reduces uncertainty significantly without also reducing
> > confidence provides an adversary with better information about the
> > known location. Less reliable assumptions reduce confidence more
> > significantly than they reduce uncertainty.
> >
> > Multiple assumptions can be applied to progressively refine a
> > recovered location. The more assumptions that are used, the more
> > likely it is that any one assumption is bad. Applying a bad
> > assumption could lead to the recovered location being different to
> the
> > known location. Therefore, each assumption that is applied reduces
> > the adversary's confidence in the recovered location.
> >
> > [[I considered discussing the option of increasing confidence here,
> > which would be possible: using the assumption to confirm something.
> > However, increasing confidence has the same net effect as reducing
> > uncertainty when scaling of uncertainty is considered, so I decided
> to
> > keep things simple ... hah.]]
>
> The last 2 paragraphs sound very theoretical to me and all this talk
> about confidence and so on will not help the reader a lot.
> A designer of a new algorithm will not be provided with enough
> information to develop a better algorithm and an adversary will
> hopefully know more.
> I don't believe we even define "confidence" in the document to begin
> with.

The idea of confidence is probably something that needs to be discussed. I would like to reopen the discussion on whether to adopt -uncertainty at some point. Having a reference like that would be useful in times like this.

> > The goal of the obscuring algorithm is to limit the ability of an
> > adversary to recover location information, even when a number of
> > correct assumptions can be made.
> >
> > .h3 Basic Assumptions
> >
>
> I wouldn't use the term "assumptions" here. We are talking about
> requirements or goals (as it was called in a previous section).
> Additionally, it would be useful to point out that these "requirements"
> are design wishes of the authors for future algorithms.

Basic Goals

> > A location recipient in possession of one or more reported locations
> > SHOULD have no more information about any known location without
> > making any assumptions about the nature of the known location. That
> > is, an algorithm SHOULD NOT reveal any more information than its
> > inputs specify to an adversary that makes no assumptions.
> >
> > The following assumptions are considered important for the
> development
> > of an algorithm that obscures location. These assumptions are
> > considered to have a high probability of being correct and are
> > therefore the most important assumptions to protect against.
> >
> > For each assumption, the recipient SHOULD be unable to recover the
> > known location with less uncertainty than the reported location when
> > the assumption is correct.
> >
> > Stationary assumption: An algorithm SHOULD obscure the location of a
> > stationary target.
>
> It might be useful to add that the challenge here is that a sequence
> of reported location may allow an adversary to compute the
> intersection and to obtain more information about the known location
> as a consequence.

I considered this, but it felt like it was too specific, and this text is already too long, even with the bits you have already suggested be cut.

> > A location recipient SHOULD be unable to
> > recover the known location by assuming that the target is
> > stationary.
> >
> > Continuous movement assumption: An algorithm SHOULD obscure the
> > location of a moving target. A location recipient SHOULD be
> > unable to recover the known location by assuming that the target
> > is moving at a constant speed or with a constraint on
> > acceleration.
> >
> > The description of the algorithm SHOULD include information on
> > what is revealed about a moving target. This includes direction
> > of movement, speed and acceleration.
> >
> > Same place assumption: An algorithm SHOULD obscure the details of a
> > frequently visited place. A location recipient SHOULD be unable
> > to recover the location of the target by assuming that they are
> > the same place as was in a previous reported location.
> >
> > Same course assumption: As for the frequently visited destination,
> > but for a path that the target follows.
> >
> > The description of the algorithm SHOULD indicate whether the
> > algorithm prevents a recipient from identifying whether different
> > reported locations correspond to the same known location, and
> > under what circumstances. This would permit a recipient to learn
> > that the same location is being visited, even if the identity of
> > that location is obscured.
> >
> > High accuracy assumption: A location recipient SHOULD be unable to
> > recover the known location by assuming that the known location has
> > low uncertainty or is updated frequently.
> >
> > An analysis of the algorithm based on a continuous series of
> > perfect known locations is desirable.
> >
> > An algorithm may also provide protection for the speed or velocity
> > of a target. It is desirable that the precise speed of a target
> > cannot be easily learned.
>
> s/may/MAY.

Ack.

> >
> > .h3 Additional Assumptions

...Goals.

> > Discussion of any additional assumptions that are either rendered
> > ineffective or especially effective is useful in evaluating an
> > algorithm.
> >
> > The following assumptions depend on the location recipient having
> > additional information, such as topological or demographic data
> > available.
> >
> > Constrained movement assumption: A location recipient MAY be
> > unable to recover the known location by assuming that the target
> > is unable (or less likely) to be located in certain locations.
> >
> > For instance, a location recipient might assume that the target
> > is more likely to be found on a road or footpath. Similarly, by
> > assuming that the target is unlikely be found in a body of
> > water, the known location could be recovered.
> >
> > A more sophisticated assumption of constrained movement uses
> > knowledge of how different locations are connected. An
> > adversary could know that to transit between two points is only
> > possible by following a small set of paths.
> >
> > Goal driven movement assumption: A location recipient MAY be
> > unable to recover the known location by assuming that the
> > movement of the target is driven by a desire to move from one
> > place to another. By using information on relative frequency of
> > different paths, a particular path might be selected with higher
> > probability based on the reported locations.
> >
> > Behavioral or past history assumption: A location recipient MAY be
> > unable to recover the known location by assuming that the target
> > is following pre-established patterns of behavior. These
> > patterns could be derived either from past knowledge of the
> > target, or demographic data that might be refined based on other
> > knowledge about the target.
> >
> > Addressing these additional assumptions is desirable, but
> > potentially difficult. Integrating additional data increases
> > algorithm
> complexity
> > and data might not be available to all implementations.
> >
>
> Will look at the algorithm writeup soon.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Thursday, July 21, 2011

Re: [Geopriv] Call for consensus on fuzzing text for geopriv-policy

Hi Hannes,

On Jul 22, 2011, at 12:12 AM, Hannes Tschofenig wrote:

> Hi Alissa, Hi Martin,
>
> your proposed algorithm assumes that there is a trigger point that is stored with each Target & location recipient.
> Jorge's algorithm did not make use of the same state requirement and instead had a grid pre-defined, as you known.
>
> You don't seem to like the grid-based approach. Any specific reason for not using the grid-based mechanism?
> We would then have an algorithm that is similar to what is currently in the document.

Recall the plan that was made at the last IETF meeting:


> From: "Thomson, Martin" <Martin.Thomson@commscope.com>
> Date: March 30, 2011 2:11:17 PM GMT+01:00
> To: "geopriv@ietf.org" <geopriv@ietf.org>
> Cc: "James M. Polk" <jmpolk@cisco.com>
> Subject: [Geopriv] geopriv-policy plans
>
> We got together this morning to discuss the plans for geopriv-policy.
>
> The plan was to create the following issues in the WG tracker:
>
> - create a registry for location obscuring algorithms
> - describe the mechanism for algorithm selection
> - describe the goals (not requirements!) for algorithms
> - select/define and describe the old algorithm (this requires making the algorithm complete)
> - complete and describe Jorge's algorithm
>
> Only the first three of these are absolutely critical for us to progress the draft. We want to do that by May 15.
>
> We have commitments from myself and Jorge to do this, but we'll need WG feedback if we are going to complete these tasks by our self-imposed deadline of May 15.

This text aims to complete the third and fourth bullets of the plan. I think you are referring to the fifth bullet, the text for which has not been provided by anyone as far as I know.

Best,
Alissa


>
>> .h3 Basic Assumptions
>>
>> A location recipient in possession of one or more reported locations
>> SHOULD have no more information about any known location without
>> making any assumptions about the nature of the known location.
>> That
>> is, an algorithm SHOULD NOT reveal any more information than its
>> inputs specify to an adversary that makes no assumptions.
>
> I am not sure how much these two paragraphs add. Everything succeeds and fails with the assumptions.
>
> For example, if a Target moves and the reported location changes (which it certainly has to at a certain point in time in any practical setup).
> This already tells the location recipient that the target is not stationary.
>
>>
>> .h2 Simple Obscuring Algorithm
>>
>> This algorithm takes a single distance in meters. It produces a
>> reported location with circular uncertainty area of that radius or
>> greater.
>>
>> As each known location is generated or received at the location
>> server:
>>
>> 1. Determine the distance between the centroid of the known location
>> to the trigger point. If there is no trigger point saved for this
>> target and location recipient, assume this distance is infinite.
>
>> If this distance is less than the input, do not report the location
>> and end the algorithm.
>>
>
> Here it needs to be ensured that in the stationary case the distance is always aways greater than the input since otherwise the location recipient does not get location reported anymore.
>
>> 2. Convert the known location to a circle
>> [I-D.thomson-geopriv-uncertainty].
>
> Is this a normative dependency?
>
>>
>> 3. Set the trigger point to the centroid of the known location.
>>
>
>
> I believe it would be more clear to re-set the trigger point in step 4 in case you end the algorithm since otherwise the re-setting it to the centroid of the known location makes no sense given that you re-set it again in a latter step.
> Something like:
>
> 4. If the known location has uncertainty equal to or greater than the
> input, report the known location, reset the trigger point to the centroid of the known location, and end the algorithm.
>
>> 4. If the known location has uncertainty equal to or greater than the
>> input, report the known location and end the algorithm.
>>
>> 5. Select two uniformly distributed random numbers [RFC4086] between 0
>> and 1.
>>
>> 6. Set the centroid of the reported location by moving the centroid of
>> the known location randomly, using the two random numbers:
>>
>> - The distance is determined by taking the square root of the first
>> number and multiplying it by the difference between the input and
>> the uncertainty (radius) of the known location.
>
>>
>> - The angle (or heading) is determined by multiplying the second
>> number by 360 degrees (or 2*pi radians).
>>
> Could you explain your motivation for computing the distance and the angle in this specific fashion?
>
>
>> 7. Set the uncertainty radius of the reported location to the input.
>
> If you do this wouldn't the system have location reports with a radius that equals the input value.
> For example, imagine that you have a system that uses GPS then the known location would have a fairly small uncertainty radius (almost always).
> Hence, almost all reported locations would have an uncertainty radius that corresponds to the input of the rule maker.
>
>>
>> 8. Move the trigger point randomly by half the input using the process
>> used in Step 6 with a new pair of random numbers. Save the trigger
>> point for this target and location recipient.
>>
>> 9. Report the randomized location and end the algorithm.
>>
>
>
> Ciao
> Hannes
>
>


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Call for consensus on fuzzing text for geopriv-policy

Hi Alissa, Hi Martin,

your proposed algorithm assumes that there is a trigger point that is stored with each Target & location recipient.
Jorge's algorithm did not make use of the same state requirement and instead had a grid pre-defined, as you known.

You don't seem to like the grid-based approach. Any specific reason for not using the grid-based mechanism?
We would then have an algorithm that is similar to what is currently in the document.

> .h3 Basic Assumptions
>
> A location recipient in possession of one or more reported locations
> SHOULD have no more information about any known location without
> making any assumptions about the nature of the known location.
> That
> is, an algorithm SHOULD NOT reveal any more information than its
> inputs specify to an adversary that makes no assumptions.

I am not sure how much these two paragraphs add. Everything succeeds and fails with the assumptions.

For example, if a Target moves and the reported location changes (which it certainly has to at a certain point in time in any practical setup).
This already tells the location recipient that the target is not stationary.

>
> .h2 Simple Obscuring Algorithm
>
> This algorithm takes a single distance in meters. It produces a
> reported location with circular uncertainty area of that radius or
> greater.
>
> As each known location is generated or received at the location
> server:
>
> 1. Determine the distance between the centroid of the known location
> to the trigger point. If there is no trigger point saved for this
> target and location recipient, assume this distance is infinite.

> If this distance is less than the input, do not report the location
> and end the algorithm.
>

Here it needs to be ensured that in the stationary case the distance is always aways greater than the input since otherwise the location recipient does not get location reported anymore.

> 2. Convert the known location to a circle
> [I-D.thomson-geopriv-uncertainty].

Is this a normative dependency?

>
> 3. Set the trigger point to the centroid of the known location.
>


I believe it would be more clear to re-set the trigger point in step 4 in case you end the algorithm since otherwise the re-setting it to the centroid of the known location makes no sense given that you re-set it again in a latter step.
Something like:

4. If the known location has uncertainty equal to or greater than the
input, report the known location, reset the trigger point to the centroid of the known location, and end the algorithm.

> 4. If the known location has uncertainty equal to or greater than the
> input, report the known location and end the algorithm.
>
> 5. Select two uniformly distributed random numbers [RFC4086] between 0
> and 1.
>
> 6. Set the centroid of the reported location by moving the centroid of
> the known location randomly, using the two random numbers:
>
> - The distance is determined by taking the square root of the first
> number and multiplying it by the difference between the input and
> the uncertainty (radius) of the known location.

>
> - The angle (or heading) is determined by multiplying the second
> number by 360 degrees (or 2*pi radians).
>
Could you explain your motivation for computing the distance and the angle in this specific fashion?


> 7. Set the uncertainty radius of the reported location to the input.

If you do this wouldn't the system have location reports with a radius that equals the input value.
For example, imagine that you have a system that uses GPS then the known location would have a fairly small uncertainty radius (almost always).
Hence, almost all reported locations would have an uncertainty radius that corresponds to the input of the rule maker.

>
> 8. Move the trigger point randomly by half the input using the process
> used in Step 6 with a new pair of random numbers. Save the trigger
> point for this target and location recipient.
>
> 9. Report the randomized location and end the algorithm.
>


Ciao
Hannes

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] IPR Disclosure: Qualcomm Incorporated's Statement aboutIPR related to draft-ietf-geopriv-held-measurements-03 (3)

An early 1980's BLM Alaska lightning detection and mapping system provided
similar functionality - the server was a DG Desktop computer running AOS
linked into a network of lightning detection sensors. A lightning strike
location was computed based on triangulation information provided by the
sensors. A GIS was used to render the base maps and the location of the
lightning strikes.

Cheers

Carl

----- Original Message -----
From: "IETF Secretariat" <ietf-ipr@ietf.org>
To: <martin.thomson@andrew.com>; <james.winterbottom@andrew.com>
Cc: <geopriv@ietf.org>; <ipr-announce@ietf.org>
Sent: Thursday, July 21, 2011 11:31 AM
Subject: [Geopriv] IPR Disclosure: Qualcomm Incorporated's Statement
aboutIPR related to draft-ietf-geopriv-held-measurements-03 (3)


>
> Dear Martin Thomson, James Winterbottom:
>
> An IPR disclosure that pertains to your Internet-Draft entitled "Using
> Device-
> provided Location-Related Measurements in Location Configuration
> Protocols"
> (draft-ietf-geopriv-held-measurements) was submitted to the IETF
> Secretariat on
> 2011-07-13 and has been posted on the "IETF Page of Intellectual Property
> Rights
> Disclosures" (https://datatracker.ietf.org/ipr/1590/). The title of the
> IPR
> disclosure is "Qualcomm Incorporated's Statement about IPR related to
> draft-
> ietf-geopriv-held-measurements-03 (3)."");
>
> The IETF Secretariat
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Call for consensus on fuzzing text for geopriv-policy

Hi Alissa, Hi Martin,

On Jul 17, 2011, at 10:32 AM, Alissa Cooper wrote:

> We'd like to get draft-ietf-geopriv-policy back to the IESG by the end of IETF 81.
>
> Upon request from the chairs, Martin Thomson has drafted the text below describing (1) the fuzzing algorithm evaluation criteria and (2) the performance of one algorithm against these criteria (a simple circle-based algorithm). We'd like to know if we have rough consensus to incorporate this text into the document so we can send it back to the IESG. Please express your opinion to the list by Friday, July 22 (even if it's just, "yes, incorporate the text").
>
> Thanks,
> Alissa
>
> ---------------
>
>
> .h1 Location Obscuring Algorithm
>
> The purpose of a location obscuring algorithm is to provide a location
> recipient (LR) with location information of reduced quality. The
> intent is to provide an LR with location information that is correct,
> but insufficient to identify the known location without a chosen
> amount of uncertainty.

... but insufficient to determine the more precise location information as available to the location server, referred as 'known location'.

>
> The obscuring algorithm takes a series of _known locations_, which
> might have greater accuracy than the recipient is permitted to
> receive. The obscuring process produces a series of _reported
> locations_.
>
> Location changes over time. A number of algorithms for obscuring the
> location of stationary targets exist
> [http://portal.acm.org/citation.cfm?id=1770566],
> [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.1678&rep=rep1&type=pdf],
> but are of questionable value when a target moves.
>

We don't do us a favor with such a text. We could argue with the authors of their proposal on why exactly we find them questionable but it does not help our document in any way.
I would suggest to delete the paragraph. We then also do not have to add these new references.

> This section describes the goals for a location obscuring algorithm.
> The normative "SHOULD" is used to describe goals, since it could be
> impossible for any single algorithm to address all the described
> goals. It is expected that some goals are only partially or
> conditionally achieved by each algorithm.

I would change this paragraph and also the beginning of the next section to:
"
.h2 Algorithm Goals

This section lists design goals for location obscuring algorithms. The algorithm described in this document meets these goals
and authors of yet-to-be-defined location obscuring algorithms are encouraged to consider these design goals as well.
For convenience reasons we use RFC 2119 language to indicate the different levels of importance of the individual design goals.
It could be impossible for any single algorithm to address all the describe goals and certain design goals may only be partially or conditionally achieved by a specific algorithm.
"

I am personally not a huge fan of normative statements about future algorithms because it almost sounds like the 'using protocol' requirements to me. Often the environment and technology changes and so the requirements then tend to be out of sync with what we have written. We say that with the using protocol requirements quite nicely and you had also objected to some of those. They also looked great at the time of writing...


>
> .h2 Algorithm Structure
>
> The algorithm SHOULD accept known locations with uncertainty and
> produce reported locations with uncertainty that encloses the known
> location at that time. That is, the reported location is no less
> correct than the known location.
>
> An obscuring algorithm MUST include a description of the user-selected
> inputs it uses and how those inputs affect output of the algorithm.
>
> Usability is an important consideration in selecting which inputs an
> algorithm uses. A rule maker (RM) needs to be able to quickly and
> easily comprehend the impact of a choosing any available option.
>
> This document describes a single input parameter: a distance in
> meters. Algorithms that use this parameter ensure that there is at
> least this much uncertainty in the reported location. Algorithms
> SHOULD restrict their inputs to this one parameter to aid usability.
>
> .h2 Algorithm Assessment
>
> The effectiveness of an obscuring algorithm under all circumstances
> might be imperfect. An assessment of effectiveness helps a rule maker
> decide if an algorithm is appropriate.

... is appropriate for a specific application usage, context, and deployment environment.

>
> An algorithm is measured against its goals. An algorithm that aims to
> convey a chosen amount of uncertainty is only partially effective if
> there are conditions where a location recipient is able to recover
> location with less uncertainty. Determining the frequency or
> probability of these conditions and the degree to which uncertainty is
> reduced is the goal of an assessment.
>
> Assessment of an algorithm MUST assume that the location
> recipient knows the choices made by the rule maker, which includes the
> details of the algorithm and the selected inputs.

I am not sure I capture the essence of the sentences. Are you trying to say that transparency is an important property in the design and all parties must have access to the algorithm description so that they can make (maybe via a third party) an assessment of the quality of the algorithm. If that's the idea I am fully on board with it. Transparency is important. (The same holds true for security algorithms as well.)

>
> This section describes one possible framework that aids in assessing
> algorithms.
>
> The goal of the adversary or attacker is to derive information about
> the known location from the reported location.
>
> In order to recover location, an adversary makes assumptions
> [Duckham05] about the location of the target.
The adversary makes assumptions about which location. It would only see the reported location but most likely the assumptions apply to the known location.
With assumption you are most likely referring to things like that the target follows certain landmarks, or so. Right? An example of the type of assumptions you have in mind would be useful.

I am also not quite sure about the value of the reference. While I had read the paper a while ago I am not sure from reading the sentence of what specifically you are making the reference to it for.


> These assumptions are
> applied to the reported location to produce a recovered location that
> has lower uncertainty than the reported location.
>
> recovered = apply(reported, assumption)
>
> where:
>
> uncertainty(recovered) <= uncertainty(reported)
> confidence(recovered) <= confidence(reported)
>

This sounds nice (for a paper) but in fact it does not add a lot for the rest of the writeup. Maybe we could shorten this text by omitting that part.

> The assumptions that a recipient is forced to make to recover
> information determines how effective an algorithm is.

Wouldn't you also, like in security, consider the amount of reported location samples the adversary collected or the computational effort he has to make?
Of course you could call this an "assumption"....

> An assumption
> that reduces uncertainty significantly without also reducing
> confidence provides an adversary with better information about the
> known location. Less reliable assumptions reduce confidence more
> significantly than they reduce uncertainty.
>
> Multiple assumptions can be applied to progressively refine a
> recovered location. The more assumptions that are used, the more
> likely it is that any one assumption is bad. Applying a bad
> assumption could lead to the recovered location being different to the
> known location. Therefore, each assumption that is applied reduces
> the adversary's confidence in the recovered location.
>
> [[I considered discussing the option of increasing confidence here,
> which would be possible: using the assumption to confirm something.
> However, increasing confidence has the same net effect as reducing
> uncertainty when scaling of uncertainty is considered, so I decided to
> keep things simple ... hah.]]

The last 2 paragraphs sound very theoretical to me and all this talk about confidence and so on will not help the reader a lot.
A designer of a new algorithm will not be provided with enough information to develop a better algorithm and an adversary will hopefully know more.
I don't believe we even define "confidence" in the document to begin with.

>
> The goal of the obscuring algorithm is to limit the ability of an
> adversary to recover location information, even when a number of
> correct assumptions can be made.
>
> .h3 Basic Assumptions
>

I wouldn't use the term "assumptions" here. We are talking about requirements or goals (as it was called in a previous section).
Additionally, it would be useful to point out that these "requirements" are design wishes of the authors for future algorithms.


> A location recipient in possession of one or more reported locations
> SHOULD have no more information about any known location without
> making any assumptions about the nature of the known location. That
> is, an algorithm SHOULD NOT reveal any more information than its
> inputs specify to an adversary that makes no assumptions.
>
> The following assumptions are considered important for the development
> of an algorithm that obscures location. These assumptions are
> considered to have a high probability of being correct and are
> therefore the most important assumptions to protect against.
>
> For each assumption, the recipient SHOULD be unable to recover the
> known location with less uncertainty than the reported location when
> the assumption is correct.
>
> Stationary assumption: An algorithm SHOULD obscure the location of a
> stationary target.

It might be useful to add that the challenge here is that a sequence of reported location may allow an adversary to compute the intersection and to obtain more information about the known location as a consequence.

> A location recipient SHOULD be unable to
> recover the known location by assuming that the target is
> stationary.
>
> Continuous movement assumption: An algorithm SHOULD obscure the
> location of a moving target. A location recipient SHOULD be
> unable to recover the known location by assuming that the target
> is moving at a constant speed or with a constraint on
> acceleration.
>
> The description of the algorithm SHOULD include information on
> what is revealed about a moving target. This includes direction
> of movement, speed and acceleration.
>
> Same place assumption: An algorithm SHOULD obscure the details of a
> frequently visited place. A location recipient SHOULD be unable
> to recover the location of the target by assuming that they are
> the same place as was in a previous reported location.
>
> Same course assumption: As for the frequently visited destination,
> but for a path that the target follows.
>
> The description of the algorithm SHOULD indicate whether the
> algorithm prevents a recipient from identifying whether different
> reported locations correspond to the same known location, and
> under what circumstances. This would permit a recipient to learn
> that the same location is being visited, even if the identity of
> that location is obscured.
>
> High accuracy assumption: A location recipient SHOULD be unable to
> recover the known location by assuming that the known location has
> low uncertainty or is updated frequently.
>
> An analysis of the algorithm based on a continuous series of
> perfect known locations is desirable.
>
> An algorithm may also provide protection for the speed or velocity of
> a target. It is desirable that the precise speed of a target cannot
> be easily learned.

s/may/MAY.


>
> .h3 Additional Assumptions
>
> Discussion of any additional assumptions that are either rendered
> ineffective or especially effective is useful in evaluating an
> algorithm.
>
> The following assumptions depend on the location recipient having
> additional information, such as topological or demographic data
> available.
>
> Constrained movement assumption: A location recipient MAY be
> unable to recover the known location by assuming that the target
> is unable (or less likely) to be located in certain locations.
>
> For instance, a location recipient might assume that the target
> is more likely to be found on a road or footpath. Similarly, by
> assuming that the target is unlikely be found in a body of
> water, the known location could be recovered.
>
> A more sophisticated assumption of constrained movement uses
> knowledge of how different locations are connected. An
> adversary could know that to transit between two points is only
> possible by following a small set of paths.
>
> Goal driven movement assumption: A location recipient MAY be
> unable to recover the known location by assuming that the
> movement of the target is driven by a desire to move from one
> place to another. By using information on relative frequency of
> different paths, a particular path might be selected with higher
> probability based on the reported locations.
>
> Behavioral or past history assumption: A location recipient MAY be
> unable to recover the known location by assuming that the target
> is following pre-established patterns of behavior. These
> patterns could be derived either from past knowledge of the
> target, or demographic data that might be refined based on other
> knowledge about the target.
>
> Addressing these additional assumptions is desirable, but potentially
> difficult. Integrating additional data increases algorithm complexity
> and data might not be available to all implementations.
>

Will look at the algorithm writeup soon.

Ciao
Hannes


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-geopriv-held-measurements-03 (3)

Dear Martin Thomson, James Winterbottom:

An IPR disclosure that pertains to your Internet-Draft entitled "Using Device-
provided Location-Related Measurements in Location Configuration Protocols"
(draft-ietf-geopriv-held-measurements) was submitted to the IETF Secretariat on
2011-07-13 and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1590/). The title of the IPR
disclosure is "Qualcomm Incorporated's Statement about IPR related to draft-
ietf-geopriv-held-measurements-03 (3)."");

The IETF Secretariat

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, July 19, 2011

Re: [Geopriv] [xmpp] Combining XMPP and GEOPRIV

On Jul 19, 2011, at 5:27 PM, James M. Polk wrote:

> Richard
>
> ending at 12:30 or 11:30?
>

I assume that to be a typo--It should say 1130.

Thanks!

Ben.

> James
>
> At 04:56 PM 7/19/2011, Richard L. Barnes wrote:
>> Dear XMPP and GEOPRIV participants,
>>
>> A brief agenda update, which should be reflected on the official agenda soon:
>>
>> In order to resolve the conflict between XMPP and GEOPRIV on Tuesday morning of the IETF meeting, the chairs of the two groups have decided to run their sessions in sequence instead of in parallel. The 150-minute morning session will be divided into two 75-minute sessions.
>>
>> XMPP: 09:00 - 10:15
>> GEOPRIV: 10:15 - 12:30
>>
>> Both session will be held in room 206A, the room previously assigned for the GEOPRIV session. The agendas for the individual sessions will of course be posted on the meeting materials pages.
>>
>> Sincerely,
>> GEOPRIV and XMPP co-chairs
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Combining XMPP and GEOPRIV

Richard

ending at 12:30 or 11:30?

James

At 04:56 PM 7/19/2011, Richard L. Barnes wrote:
>Dear XMPP and GEOPRIV participants,
>
>A brief agenda update, which should be reflected on the official agenda soon:
>
>In order to resolve the conflict between XMPP and GEOPRIV on Tuesday
>morning of the IETF meeting, the chairs of the two groups have
>decided to run their sessions in sequence instead of in
>parallel. The 150-minute morning session will be divided into two
>75-minute sessions.
>
>XMPP: 09:00 - 10:15
>GEOPRIV: 10:15 - 12:30
>
>Both session will be held in room 206A, the room previously assigned
>for the GEOPRIV session. The agendas for the individual sessions
>will of course be posted on the meeting materials pages.
>
>Sincerely,
>GEOPRIV and XMPP co-chairs
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Combining XMPP and GEOPRIV

Dear XMPP and GEOPRIV participants,

A brief agenda update, which should be reflected on the official agenda soon:

In order to resolve the conflict between XMPP and GEOPRIV on Tuesday morning of the IETF meeting, the chairs of the two groups have decided to run their sessions in sequence instead of in parallel. The 150-minute morning session will be divided into two 75-minute sessions.

XMPP: 09:00 - 10:15
GEOPRIV: 10:15 - 12:30

Both session will be held in room 206A, the room previously assigned for the GEOPRIV session. The agendas for the individual sessions will of course be posted on the meeting materials pages.

Sincerely,
GEOPRIV and XMPP co-chairs
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Sunday, July 17, 2011

[Geopriv] Call for consensus on fuzzing text for geopriv-policy

We'd like to get draft-ietf-geopriv-policy back to the IESG by the end of IETF 81.

Upon request from the chairs, Martin Thomson has drafted the text below describing (1) the fuzzing algorithm evaluation criteria and (2) the performance of one algorithm against these criteria (a simple circle-based algorithm). We'd like to know if we have rough consensus to incorporate this text into the document so we can send it back to the IESG. Please express your opinion to the list by Friday, July 22 (even if it's just, "yes, incorporate the text").

Thanks,
Alissa

---------------


.h1 Location Obscuring Algorithm

The purpose of a location obscuring algorithm is to provide a location
recipient (LR) with location information of reduced quality. The
intent is to provide an LR with location information that is correct,
but insufficient to identify the known location without a chosen
amount of uncertainty.

The obscuring algorithm takes a series of _known locations_, which
might have greater accuracy than the recipient is permitted to
receive. The obscuring process produces a series of _reported
locations_.

Location changes over time. A number of algorithms for obscuring the
location of stationary targets exist
[http://portal.acm.org/citation.cfm?id=1770566],
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.1678&rep=rep1&type=pdf],
but are of questionable value when a target moves.

This section describes the goals for a location obscuring algorithm.
The normative "SHOULD" is used to describe goals, since it could be
impossible for any single algorithm to address all the described
goals. It is expected that some goals are only partially or
conditionally achieved by each algorithm.

.h2 Algorithm Structure

The algorithm SHOULD accept known locations with uncertainty and
produce reported locations with uncertainty that encloses the known
location at that time. That is, the reported location is no less
correct than the known location.

An obscuring algorithm MUST include a description of the user-selected
inputs it uses and how those inputs affect output of the algorithm.

Usability is an important consideration in selecting which inputs an
algorithm uses. A rule maker (RM) needs to be able to quickly and
easily comprehend the impact of a choosing any available option.

This document describes a single input parameter: a distance in
meters. Algorithms that use this parameter ensure that there is at
least this much uncertainty in the reported location. Algorithms
SHOULD restrict their inputs to this one parameter to aid usability.

.h2 Algorithm Assessment

The effectiveness of an obscuring algorithm under all circumstances
might be imperfect. An assessment of effectiveness helps a rule maker
decide if an algorithm is appropriate.

An algorithm is measured against its goals. An algorithm that aims to
convey a chosen amount of uncertainty is only partially effective if
there are conditions where a location recipient is able to recover
location with less uncertainty. Determining the frequency or
probability of these conditions and the degree to which uncertainty is
reduced is the goal of an assessment.

Assessment of an algorithm MUST assume that the location
recipient knows the choices made by the rule maker, which includes the
details of the algorithm and the selected inputs.

This section describes one possible framework that aids in assessing
algorithms.

The goal of the adversary or attacker is to derive information about
the known location from the reported location.

In order to recover location, an adversary makes assumptions
[Duckham05] about the location of the target. These assumptions are
applied to the reported location to produce a recovered location that
has lower uncertainty than the reported location.

recovered = apply(reported, assumption)

where:

uncertainty(recovered) <= uncertainty(reported)
confidence(recovered) <= confidence(reported)

The assumptions that a recipient is forced to make to recover
information determines how effective an algorithm is. An assumption
that reduces uncertainty significantly without also reducing
confidence provides an adversary with better information about the
known location. Less reliable assumptions reduce confidence more
significantly than they reduce uncertainty.

Multiple assumptions can be applied to progressively refine a
recovered location. The more assumptions that are used, the more
likely it is that any one assumption is bad. Applying a bad
assumption could lead to the recovered location being different to the
known location. Therefore, each assumption that is applied reduces
the adversary's confidence in the recovered location.

[[I considered discussing the option of increasing confidence here,
which would be possible: using the assumption to confirm something.
However, increasing confidence has the same net effect as reducing
uncertainty when scaling of uncertainty is considered, so I decided to
keep things simple ... hah.]]

The goal of the obscuring algorithm is to limit the ability of an
adversary to recover location information, even when a number of
correct assumptions can be made.

.h3 Basic Assumptions

A location recipient in possession of one or more reported locations
SHOULD have no more information about any known location without
making any assumptions about the nature of the known location. That
is, an algorithm SHOULD NOT reveal any more information than its
inputs specify to an adversary that makes no assumptions.

The following assumptions are considered important for the development
of an algorithm that obscures location. These assumptions are
considered to have a high probability of being correct and are
therefore the most important assumptions to protect against.

For each assumption, the recipient SHOULD be unable to recover the
known location with less uncertainty than the reported location when
the assumption is correct.

Stationary assumption: An algorithm SHOULD obscure the location of a
stationary target. A location recipient SHOULD be unable to
recover the known location by assuming that the target is
stationary.

Continuous movement assumption: An algorithm SHOULD obscure the
location of a moving target. A location recipient SHOULD be
unable to recover the known location by assuming that the target
is moving at a constant speed or with a constraint on
acceleration.

The description of the algorithm SHOULD include information on
what is revealed about a moving target. This includes direction
of movement, speed and acceleration.

Same place assumption: An algorithm SHOULD obscure the details of a
frequently visited place. A location recipient SHOULD be unable
to recover the location of the target by assuming that they are
the same place as was in a previous reported location.

Same course assumption: As for the frequently visited destination,
but for a path that the target follows.

The description of the algorithm SHOULD indicate whether the
algorithm prevents a recipient from identifying whether different
reported locations correspond to the same known location, and
under what circumstances. This would permit a recipient to learn
that the same location is being visited, even if the identity of
that location is obscured.

High accuracy assumption: A location recipient SHOULD be unable to
recover the known location by assuming that the known location has
low uncertainty or is updated frequently.

An analysis of the algorithm based on a continuous series of
perfect known locations is desirable.

An algorithm may also provide protection for the speed or velocity of
a target. It is desirable that the precise speed of a target cannot
be easily learned.

.h3 Additional Assumptions

Discussion of any additional assumptions that are either rendered
ineffective or especially effective is useful in evaluating an
algorithm.

The following assumptions depend on the location recipient having
additional information, such as topological or demographic data
available.

Constrained movement assumption: A location recipient MAY be
unable to recover the known location by assuming that the target
is unable (or less likely) to be located in certain locations.

For instance, a location recipient might assume that the target
is more likely to be found on a road or footpath. Similarly, by
assuming that the target is unlikely be found in a body of
water, the known location could be recovered.

A more sophisticated assumption of constrained movement uses
knowledge of how different locations are connected. An
adversary could know that to transit between two points is only
possible by following a small set of paths.

Goal driven movement assumption: A location recipient MAY be
unable to recover the known location by assuming that the
movement of the target is driven by a desire to move from one
place to another. By using information on relative frequency of
different paths, a particular path might be selected with higher
probability based on the reported locations.

Behavioral or past history assumption: A location recipient MAY be
unable to recover the known location by assuming that the target
is following pre-established patterns of behavior. These
patterns could be derived either from past knowledge of the
target, or demographic data that might be refined based on other
knowledge about the target.

Addressing these additional assumptions is desirable, but potentially
difficult. Integrating additional data increases algorithm complexity
and data might not be available to all implementations.

.h2 Simple Obscuring Algorithm

This algorithm takes a single distance in meters. It produces a
reported location with circular uncertainty area of that radius or
greater.

As each known location is generated or received at the location
server:

1. Determine the distance between the centroid of the known location
to the trigger point. If there is no trigger point saved for this
target and location recipient, assume this distance is infinite.
If this distance is less than the input, do not report the location
and end the algorithm.

2. Convert the known location to a circle
[I-D.thomson-geopriv-uncertainty].

3. Set the trigger point to the centroid of the known location.

4. If the known location has uncertainty equal to or greater than the
input, report the known location and end the algorithm.

5. Select two uniformly distributed random numbers [RFC4086] between 0
and 1.

6. Set the centroid of the reported location by moving the centroid of
the known location randomly, using the two random numbers:

- The distance is determined by taking the square root of the first
number and multiplying it by the difference between the input and
the uncertainty (radius) of the known location.

- The angle (or heading) is determined by multiplying the second
number by 360 degrees (or 2*pi radians).

7. Set the uncertainty radius of the reported location to the input.

8. Move the trigger point randomly by half the input using the process
used in Step 6 with a new pair of random numbers. Save the trigger
point for this target and location recipient.

9. Report the randomized location and end the algorithm.

.h3 Simple Algorithm Assessment

This simple algorithm requires that the LS performing obscuring store
a trigger location for each location recipient. This might be reduced
to the set that have the same policy.

This algorithm only addresses the stationary assumption and the
continuous movement assumption. Same place or same path assumptions
are effective in recovering the known location.

The location of the target can be easily recovered when a recipient is
able to collect multiple reported locations for the same destination
over time. The known location is randomized differently each time the
destination is visited or path is travelled. A location recipient
that assumes same destination can intersect these to recover a
location with uncertainty which could be as good as the known
location.

The reported location produced by this algorithm always contains the
known location. This is the cause of a significant flaw, as described
[[below]].

.h3 Simple Algorithm Flaw

For certain random values, the location of the target can be precisely
revealed using two consecutive reported locations. The following
three conditions result in the known location being almost perfectly
recovered:

# The trigger point generated at the first point is moved in one
direction by the maximum distance, or close to it.

# The target moves in the same direction as the trigger point.

# The randomization of the second location moves the location in the
same direction by the maximum distance, or close to it.

# The randomization of the first location moves the location in the
opposite direction by the maximum distance, or close to it.

The resulting reported locations have center points that are almost
3.5 times the input distance apart, and the nearest points in the
reported locations 1.5 times apart. The known locations are easily
identified as being at the nearest points on the circle, since no two
consecutive points can be more than 1.5 times the input distance
apart.

In general, a reported location can be found at the intersection of
that reported location, plus two circles of radius 2.5 times the input
distance, centered at both the last and next reported locations.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, July 11, 2011

Re: [Geopriv] geopriv-arch AUTH48

Also +1

Carl

----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Cc: <geopriv@ietf.org>
Sent: Friday, July 08, 2011 1:32 PM
Subject: Re: [Geopriv] geopriv-arch AUTH48


> +1
>
> On Jul 8, 2011, at 3:14 PM, Hannes Tschofenig wrote:
>
>> Fine for me.
>>
>> On Jul 8, 2011, at 8:31 PM, Alissa Cooper wrote:
>>
>>> draft-ietf-geopriv-arch-03 is in AUTH48 and the authors have suggested a
>>> slight change to some normative language in section 4.2.4. Here is the
>>> section:
>>>
>>> An LS that receives Rules exclusively through LOs MUST examine the
>>> Rules that accompany a given LO in order to determine how the LS may
>>> use the LO (if any Rules are included by reference, the LS SHOULD
>>> attempt to download them). If the LO includes no Rules that allow
>>> the LS to transmit the LO to another entity, then the LS MUST NOT
>>> transmit the LO. If the LO contains no Rules at all (if it is in a
>>> format with no Rules syntax, for example), then the LS MUST delete it
>>> (emergency services provide an exception in that Rules can be
>>> implicit; see [15]). If the LO included Rules by reference, but
>>> these Rules were not obtained for any reason, the LS MUST NOT
>>> transmit the LO and MUST delete it.
>>>
>>> Here is the suggested change:
>>>
>>> OLD:
>>> If the LO included Rules by reference, but
>>> these Rules were not obtained for any reason, the LS MUST NOT
>>> transmit the LO and MUST delete it.
>>>
>>> NEW:
>>> If the LO included Rules by reference, but
>>> these Rules were not obtained for any reason, the LS MUST NOT
>>> transmit the LO and MUST adere to the provided value in the
>>> retention-expires field.
>>>
>>> The change has been proposed to clarify that
>>> a) if the LS does not want to re-transmit location information then it
>>> does not immediately have to delete
>>> the received location object but instead looks at the retention-expires
>>> field only.
>>> b) if the LS wants to transmit location information it is not allowed to
>>> do so. The retention-expires field would also give guidance on how long
>>> it is permitted to keep the location.
>>>
>>> Since this is a change to normative language, if folks have objections
>>> to it we're requesting that they send them to the list by next
>>> Wednesday, July 13.
>>>
>>> Thanks,
>>> Alissa
>>>
>>>
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Sunday, July 10, 2011

Re: [Geopriv] geopriv-arch AUTH48

Yeah. Much better in fact.

On 2011-07-09 at 05:32:17, Richard L. Barnes wrote:
> +1
>
> On Jul 8, 2011, at 3:14 PM, Hannes Tschofenig wrote:
>
> > Fine for me.
> >
> > On Jul 8, 2011, at 8:31 PM, Alissa Cooper wrote:
> >
> >> draft-ietf-geopriv-arch-03 is in AUTH48 and the authors have
> suggested a slight change to some normative language in section 4.2.4.
> Here is the section:
> >>
> >> An LS that receives Rules exclusively through LOs MUST examine the
> >> Rules that accompany a given LO in order to determine how the LS
> >> may use the LO (if any Rules are included by reference, the LS
> >> SHOULD attempt to download them). If the LO includes no Rules that
> >> allow the LS to transmit the LO to another entity, then the LS MUST
> >> NOT transmit the LO. If the LO contains no Rules at all (if it is
> >> in a format with no Rules syntax, for example), then the LS MUST
> >> delete
> it
> >> (emergency services provide an exception in that Rules can be
> >> implicit; see [15]). If the LO included Rules by reference, but
> >> these Rules were not obtained for any reason, the LS MUST NOT
> >> transmit the LO and MUST delete it.
> >>
> >> Here is the suggested change:
> >>
> >> OLD:
> >> If the LO included Rules by reference, but these Rules were not
> >> obtained for any reason, the LS MUST NOT transmit the LO and MUST
> >> delete it.
> >>
> >> NEW:
> >> If the LO included Rules by reference, but these Rules were not
> >> obtained for any reason, the LS MUST NOT transmit the LO and MUST
> >> adere to the provided value in the retention-expires field.
> >>
> >> The change has been proposed to clarify that
> >> a) if the LS does not want to re-transmit location information then
> >> it does not immediately have to delete the received location object
> but instead looks at the retention-expires field only.
> >> b) if the LS wants to transmit location information it is not
> allowed to do so. The retention-expires field would also give guidance
> on how long it is permitted to keep the location.
> >>
> >> Since this is a change to normative language, if folks have
> objections to it we're requesting that they send them to the list by
> next Wednesday, July 13.
> >>
> >> Thanks,
> >> Alissa
> >>
> >>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv