I'm a big fan of authorization by possession. It has a certain elegance to it.
In comparison, authorization by access control is a more difficult beast to tame. If we assume that access control relies on the authenticated identity of a location recipient, then we need a good framework for authentication.
Given the deployment model, this framework must describe how a location server authenticates requests. This is especially difficult because, in the expected deployment model, location recipients have no prior relationship with the location server.
HTTP doesn't have a framework for inter-domain authentication. On the other hand, RFC 4474 describes how an authority can provide assurances about an entity that makes a request. Thus, using SIP, it is possible to fulfil this rule condition:
<identity>
<one id="sip:alice@example.com"/>
</identity>
But, regardless of the protocol in use, this makes no sense:
<identity>
<one id="http://bob@example.com/"/>
</identity>
(For one, that's a resource, not an entity.)
This has been characterized as a problem. A missing piece. A paragon example of "magic happens here".
A few years back, I was convinced that this problem should and could be solved. It didn't take much research into SAML and OpenID and their ilk to disabuse me of the notion that there was a solution.
I've recently concluded that this "problem" doesn't need to be solved.
Examine the use case: There are groups of people that you want to authorize to different degrees. One group is not authorized at all. Another group is authorized to acquire location with no constraints. Other groups are authorized with various limitations: time, accuracy, location, etc...
Here's a clue: authorization policy allows for more than just a straight Boolean allow/deny decision based on identity.
Here's another clue: authentication is typically achieved by having the subject prove knowledge of a piece of information. For PKI, this is a private key; for basic or digest, this is a username and password; for authorization by possession, this is the location URI.
Simple authorization by possession uses selective disclosure to separate recipients into just two groups: those who are allowed to receive location (and who get a location URI), and those who aren't (and remain ignorant of the location URI).
To "solve" the problem, recipients are separated into groups by giving each group a different location URI.
The location URI becomes a substitute for the <identity> condition.
Each location URI is assigned a different policy. That policy does not include <identity> conditions - it doesn't need to. Instead, it contains all the other wonderful policy controls that we've defined: time-based conditions, location obfuscation, and so forth.
If you want to treat a particular recipient specially, then mint a location URI just for them and ensure that they are the only ones who get that URI (and that URI is the only one they can use to locate you).
Where disclosure cannot be controlled sufficiently to segregate potential recipients into the desired groups, it's possible to fall back on identity. That is where SIP, with all the glory of RFC 4474, comes into play. A LIS can provide SIP location URIs directly, or an HTTP location URI can be indirectly published to a presence server.
HELD provides a location URI set that can contain both HTTP and SIP URIs. For the resource that these identify, it would be reasonable to allow for the inclusion of policy that allowed for both forms of authentication.
Rules containing identity conditions would only apply to SIP requests; these rules might grant greater access than might otherwise be granted. Any rule containing <identity> conditions would not apply to an HTTP/HELD dereference.
This is the story I hope to tell with the HELD dereference draft. It's also the story that will make policy additions work with HELD. I also hope that Hannes' proposal for the DHCP location URI draft tells a story that is consistent with this.
--Martin
Acknowledgements: I have to credit Richard with much of this, or at least for dropping the first clue.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Wednesday, March 31, 2010
[Geopriv] Interaction of new civic elements with geopriv-policy
To the authors of drafts that introduce new civic address elements,
New civic elements are going to be a problem for those who implement geopriv-policy.
It would seem logical that the new -prefix elements fall within the "building" tag for <provide-civic> [1]. On the other hand, geopriv-policy is quite prescriptive about the fields that are included.
Worse yet, "full" would seem to be equally prescriptive of what fields are included. A strict reading would not allow a server to provide extension fields, regardless of the value of <provide-civic>.
My conclusion is that <provide-civic> needs better support for extensions. I'm interested to hear what others in the WG think.
--Martin
[1] <http://tools.ietf.org/html/draft-ietf-geopriv-policy-21#section-6.5.1>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Tuesday, March 30, 2010
Re: [Geopriv] Minutes from IETF 77
Perhaps I got a little over-optimistic in my summarizing. :) I will
drop "possession model" from the minutes before posting them, and wait
for Hannes' text.
drop "possession model" from the minutes before posting them, and wait
for Hannes' text.
All of the mechanisms we standardize need to have their authorization
stories straight -- there's no irony there.
Alissa
On Mar 30, 2010, at 2:34 PM, James M. Polk wrote:
> At 10:49 AM 3/30/2010, Alissa Cooper wrote:
>> Minutes - GEOPRIV - IETF 77
>>
>> draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
>> James gave an overview of the most recent changes and the list
>> traffic. The discussion focused on the possession vs. authorization
>> model debate, with Hannes volunteering to provide some possession
>> model text on the mailing list to help resolve the issue.
>
> respectfully - this is incorrect. Hannes volunteered to write some
> text about the authorization model -- which is what's in the doc
> now. If he was to provide possession model text, then the discussion
> would have been very different in the room, as there wasn't a good
> reason to change the existing text from authorization to possession
> -- even though I asked the chairs to take a hum of the room to see
> if the WG wanted this change. The audio will support me in saying
> the chairs refused to take this hum (that I asked for). Therefore,
> it's hard to justify this change when one wasn't agreed to in the
> room (i.e., by the WG).
>
> James
>
>
>> draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
>> The main issue discussed was getting the right authorization story
>> into the draft.
>
> the irony that this ID doesn't have its "authorization story right"
> yet draft-ietf-geopriv-dhcp-lbyr-uri-option-07 keeps getting pounded
> for its authorization story is classic.
>
> James
>
>
>> draft-thomson-geopriv-relative-location-00 (Brian Rosen)
>> The main issue discussed was what to do with the reference point
>> provided if you don't understand the extension provided by this draft
>> -- some think that the reference should be used as the location, and
>> others think that no location should be used. Discussion will
>> continue
>> on the list.
>>
>> draft-george-ecrit-lamp-post-02 (Brian Rosen)
>> Brian quickly reviewed the addition of CAtypes for lamposts, and the
>> group discussed moving this as an AD-sponsored draft.
>>
>> draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
>> Martin reviewed how measurements are used in device-aided
>> positioning.
>> The group discussed different security threats and the lack of decent
>> mitigations for them.
>>
>> Conclusion
>> The chairs asked for expressions of support for which of the
>> documents
>> group members would like to see as working group items. Support for
>> pidf-interior, deref-protocol, relative-location, and held-
>> measurements was expressed. The plan for moving forward and choosing
>> an ordering will be discussed on the list.
>>
>>
>> Raw notes from Matt Lepinski and Matt Miller follow:
>> ----------------------------------------------------------------------
>> GEOPRIV - IETF77
>>
>> Notewell
>> Agenda Bashing
>>
>> Doc Status
>> New RFCs
>> -civic-address-recommendations: RFC 5774
>> -l7-lcp-ps: RFC 5687
>> RFC Ed Queue
>> -http-location-delivery
>> -lbyr-requirements
>> IESG eval
>> -lis-discovery
>> -geo-uri
>> -loc-filters
>> -prefix
>> draft-singh-geopriv-pidf-lo-dynamic
>>
>> Thank you Cullen Jennings as outgoing AD
>> BoF location coherence Recap at lunch
>> * number of protocols out there, how to reconcile them
>> * draft upcoming
>>
>> Status of 3852bis
>> * no open issues
>> * number of changes in -08 and -09 (two technical, one editorial)
>> * Authors believe that the document is ready for WGLC
>>
>> Status of Held Identity Extensions
>> * No open issues
>> * Authors believe that the document is ready for WGLC
>>
>> draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James)
>> * (martin): more discussions needed, but allowing some points
>> * no confirmation on some issues
>> * (martin): intro missing "new to geopriv" info very bad
>> * chosen authorization model over posession model, need to explain
>> how
>> the policies are put in place
>> * the "magic happens" part needs more definition
>> * there isn't an explaination for how the policy document gets in
>> place
>> * this is a protocol extension, do we need a p2p protocol to get the
>> policy in place
>> * Alissa Cooper: allow for this mechanism to be out of scope, but the
>> draft needs to reference something that describes a solution
>> * text to get consensus on the list
>> * Martin Thompson: struggling with how posession model was rejected,
>> since others have accepted the limitations
>> * Brian Rosen: Assumed possession reasonable for DHCP, why not this?
>> * Hannes to provide text to James for inclusion
>> * Conclusion: need to add text regarding security issues (possession
>> or authorization)
>>
>> draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
>> * Henning Schulzrinne: this is a tradeoff between i18n and geomenuing
>> and the ability to odd delimiations of buildings, and cannot do this
>> for all possible subdivisions of building identifiers
>> * In many cases, one knows what a room number looks like regardless
>> of
>> language and culture
>> * Rosen: This is necessary if the creator does not know how the user
>> will use the doc; if printed is ok, but if rendering in a map may not
>> be acceptable
>> * Henning Schulzrinne: The administrator knows what rooms are, and
>> there is no doubt
>> * Rosen: Acceptable if in document, the semantics are acceptable,
>> then
>> easy comprimise would be to define the semantics of INT N="Building"
>> to be the same as the old semantics of BLDG
>> * Taking discussion to list
>> * James Winterbottom: For values to be any use, localization is very
>> important
>> * Rosen disagrees; XML needs to match pidf
>> * James Winterbottom: You do not know what to do with data without
>> localized context
>> * Chairs table discussion for mailing list (time constraint)
>>
>> draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
>> * Issue with current LIS Discovery using Access Domain from DHCP, is
>> that it may take a very long time to get deployed (particularly in
>> residential gateway environments)
>> * Bernard Aboba: This has been done in may places; trick is to
>> figuring out where to look in tree, and reverse lookups not useful or
>> available in practice
>> * Brian Rosen: Reserse DNS isn't deployed in a lot of very
>> interesting
>> situations like many DSL deployments
>> * James Winterbottom: But we have had active participants in this
>> group who work for DSL providers who have told us that this reserve
>> tree solution will work in their networks
>> * Brian Rosen: But my point is that reverse DNS isn't universal
>> * Ted Hardie: This requires a tie between public IPs vs private NATs,
>> and assumes there is a mapping between the IP spaces that may not
>> exist
>> * Bernard Aboba: In the enterprise, the enterprise has one list and
>> the provider may have another, while in consumer the user doesn't
>> have
>> a list, and the provider does
>> * James Winterbottom: The point of this draft is not to replace the
>> DHCP option. The idea is that you will always try the DHCP option
>> first and if that works, then you won't use the mechanism in this
>> draft (reverse DNS)
>> * Ted Hardie: This draft has a hard tie between the network
>> architecture and DNS tree, which exist sfor IPv6
>> * Bernard Aboda: We are going to need to try a number of different
>> things and see what works (e.g., your local address, what STUN gives
>> you, etc)
>> * Ted Hardie: So how does a 3rd party does this, how do I know that
>> this comes from me or someone else, what about the privacy issues?
>> Anyone who has my IP address can find the LIS that serves me, isn't
>> that a problem?
>> * Ray Bellis: How is anything here not already known?
>> * Ted Hardie: This expose location-related infromation (e.g., the
>> physical network that you are attached to) to an observer . Ted is
>> concerned that the 3rd party issue isn't being seen as important
>> enough
>> * Peter: The tree climbing is concerning when crossing administrative
>> boundaries, the octect boundary is arbitrary and is a weakness
>> * Andy Newton: The desire to go down this route is because DHCP will
>> take a long time to deploy ... People who run large Reverse DNS
>> space,
>> don't edit Reverse zones by hand, they use tools which also take a
>> very long time to update and get deployed. What strikes me as
>> worrisome, is that you are going to put a lot of query load on people
>> who have nothing to do with this (especially in the IPv4 case). You
>> should go to the RIR communities and see what they think abou this.
>> * Ray Bellis: valid point, and needs to be addressed
>> * Peter: To make this climbing less ugly, can we determine the
>> current
>> location lookup be a non-starter?
>> * James Winterbottom: Where this came from is an interim meeting in
>> Dallas a few years ago where we talked through a ton of options and
>> this one was deemed relatively deployable by the people who were
>> present (which included BT, in the UK)
>> * Jon Peterson: The document claims that the security concerns are
>> similar to DHCP and DNS, and this is not quite true. I'd like to see
>> more discussion of the security/privacy properties of this solution
>>
>> draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
>> * This draft describes a simple profile for derefencing http/s:
>> location URI
>> * Cullen Jennings (as an individual): The question has always been
>> how
>> the authorization works for this. (That is, how the miracle occurs
>> where the policy information from the rule-maker gets into the server
>> that is making the authorization decision)
>> * Martin Thomson: Need to have the discussion. I agree that we need
>> to
>> have a story in the document. (And maybe that story is "possession
>> model blah-blah-blah").
>> * Cullen Jennings: Once we have the story, we can argue about whether
>> it's the right story.
>> * Authors request working group adoption. Chairs said there needs to
>> be a larger working group discussion of what is the next batch of
>> documents that the group works on.
>>
>> draft-thomson-geopriv-relative-location-00 Brian
>> * Two independent efforts to describe interior location, this draft
>> combines them
>> * This draft defines an offset relative to a reference point
>> * Open Issue: Current version is that if you don't understand the
>> extension in this draft, then you get the reference point as the
>> location. Brian and the majority of the authors believe that getting
>> some location which is mostly right is better than getting no
>> location
>> at all. A minority of authors believe that you should get nothing (no
>> location) in the event that you don't understand the extension. (This
>> minority opinion claims that when the offset is large, giving someone
>> the reference as the location is worse than giving no location at
>> all).
>> * Martin Thomson: [Note: Martin supports the minority author opinion
>> described above] We're here with a new spec, and we're starting off
>> in
>> the wrong place. You're lying to everyone that looks at this
>> container. If you include the civic or grml reference, and the
>> client
>> ignores the location, then you're not getting the right location.
>> * Marc Linser: 1ts, if we take what you said first, then we wouldn't
>> be able to extend anything. 2nd, Brian stated we don't declare the
>> reference point, ...
>> * Brian: The original draft had an arbitrary string to declare what
>> the reference point is.
>> * Jon: Is there any way to declare what the uncertainty is? (That is,
>> treat it as an impercise location with uncertainty equal to the
>> magnitude of the offset)
>> * Brian: This is no way to do that today in civic.
>> * Martin: In Civic you are not clear (uncertain) about any elemeent,
>> then you should not include it. (That is, currently in a Civic
>> uncertainty is implicit in the elements that you choose to include)
>> * Brian: If you don't understand the extension, you get the reference
>> and the uncertainty. If you understand the extension, you get a more
>> precise location
>> * Brian: There are a number of issues, and we should have a list
>> discussion.
>>
>> (Mini-presentation without slides by Brian Rosen)
>> draft-george-ecrit-lamp-post-02
>> * One catype reference about a post that does not include any
>> semantic
>> numbering
>> * Another catype reference about a post that does have a significant
>> numbering
>> * (unkonwn): If you start to add references to posts, how are these
>> managed?
>> * Richard Barnes: Isn't this just a database of locations and an
>> index
>> into this database. Why don't we just treat it like that
>> * Henning Schulzrinne: This is common enough that we need to include,
>> but maybe we need a third type to abstract the posts, but this is
>> good
>> enough to move forward on. (what we have now covers maybe 80%)
>> * Suggestion that it might be appropriate to progress this document
>> as
>> an AD-sponsored draft
>>
>> draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
>> * Draft to describe co-operative positioning between devices (GPS)
>> and
>> network topology
>> * Key idea: Devices are in a good position to measure stuff related
>> to
>> location, but they generally aren't able to turn these measurements
>> into useful location. (That is, knowing that a device has a round
>> trip
>> time of X to it's cell tower doesn't do any good without knowing
>> where
>> the cell tower is). However, if the device sends measurements to a
>> server that has access to appropriate databases, then the server may
>> be able to provide more accurate location based on the measurements.
>> * Ted Hardie: I believe that there is a ton of IPR in this space. The
>> working group should consider that when trying to decide whether to
>> step into this space. (patents cover carrying this information, maybe
>> not over the wire)
>> * 3 Security Problems
>> -- Using measurements to get someone elses location without
>> authorization
>> + This is easy only if you already know the victim's location
>> + In many cases it is very difficult to get accurate measurements
>> for someone else
>> -- Using measurements to map out someone's network topology
>> + Similar limitations to the previous problem
>> + This is at least partially mitigated by rate-limiting queries
>> from clients
>> + Much of this topology information is public. If you're going to
>> broadcast radio, then it's hard to hide the fact that you have
>> network
>> infrastructure at the point of broadcast origination
>> -- Using measurements to Indirectly spoof your location (get the
>> server to lie for you)
>> + One thing to lie about your own location, another to get someone
>> else to do that for you
>> + Meansurements can be spoofed to coerce a LIS to provide false
>> data
>> + credibility the LIS has in you is gained by the proxy
>> * What to do about it...
>> - we don't care
>> + existing systems trivally spoofed, and no one cares; info used by
>> targets (navigation aids, etc), so no gain in spoofing
>> - check inputs
>> + Measurements checked just as with identifiers (assuming they can
>> be checked)
>> + Applies for all three security concerns
>> + network-based location cannot check every type, would invalidate
>> or cripple many methods
>> - Sanity check outputs
>> + compares result with independent location (e.g. LG location vs.
>> GPS coords); if location within independent location = probably
>> location, outside == definitely bad
>> + limits scope of attacks, doesn't prevent
>> - Assign blame
>> + Explicit about location info from untrusted sources
>> + Could also include verified data (appropriately labeled)
>> + trust decisions handled by recipients (which can excersize option
>> 1 at their discretion)
>> * Cullen Jennings: Some other security considerations might be things
>> like the radio strength on a device
>> * Alissa Cooper: When you say they're limited by the same mechanisms,
>> you can make the measurements up. Rate-limited may still help prevent
>> this.
>> * Alissa Cooper: Sometimes lying by proxy is a feature not a problem.
>> * James Winterbottom: I like Option 4 (Assign Blame)
>> * EKR : The options you present are related to avoiding the lying
>> issue. But none of your suggestions seem to address the privacy issue
>> * Martin Thompson: The only way to deal with the privacy issue is to
>> check the measurements. (or make sure that no one else can obtain the
>> measurements)
>> * Cullen Jennings: I'm really pessimistic that our best solutions are
>> not going to be adequate. This type of information means that we
>> shouldn't give out the specifics of how we are gaining our location.I
>> think we need to be realistic about the best we can achieve.
>> * Alissa Cooper: That you exist means your location can be
>> determined.
>> * James Winterbottom: The document just needs to clearly explain the
>> security properties and the limitations of these techniques
>> * Chiar: Does the working group think that there's a security story
>> here that with some more work we can understand?
>> * Ted Hardie: There is a security story and it's depressing.
>> * EKR: If the best security story is that my...asdfasdfasdfadsf!
>>
>> * Matt Lepinski: People are going to do this out in the wild. It
>> would
>> be better to do this here with the security concerns that exist, than
>> leave it to the masses to determine it without any concerns
>>
>> Discussion of interesting drafts
>> * relative-location +3
>> * pidf-interior +2
>>
>> Robert AD: Regardless of how many documents the working group adds to
>> the charter, there needs to be an order.
>>
>> _______________________________________________
>> 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] Minutes from IETF 77
At 01:44 PM 3/30/2010, Winterbottom, James wrote:
>My recollection is that Hannes agreed to provide text, he did not
>indicate which model he was going to provide text for.
>My recollection is that Hannes agreed to provide text, he did not
>indicate which model he was going to provide text for.
fair point - though it was not agreed he would change the model to
the possession model, which would take WG consensus to change the
ID's current text on this subject.
James
>On a slightly different note, I didn't indicate that BT were at the
>interim meeting in Dallas, I indicated that a BT representative at
>some time had suggested that the LIS discovery mechanism in the
>Thomson-Bellis draft would work for the BT network.
>
>Cheers
>James
>
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> > Of James M. Polk
> > Sent: Wednesday, 31 March 2010 5:35 AM
> > To: Alissa Cooper; geopriv@ietf.org
> > Subject: Re: [Geopriv] Minutes from IETF 77
> >
> > At 10:49 AM 3/30/2010, Alissa Cooper wrote:
> > >Minutes - GEOPRIV - IETF 77
> > >
> > >draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
> > >James gave an overview of the most recent changes and the list
> > >traffic. The discussion focused on the possession vs. authorization
> > >model debate, with Hannes volunteering to provide some possession
> > >model text on the mailing list to help resolve the issue.
> >
> > respectfully - this is incorrect. Hannes volunteered to write some
> > text about the authorization model -- which is what's in the doc now.
> > If he was to provide possession model text, then the discussion would
> > have been very different in the room, as there wasn't a good reason
> > to change the existing text from authorization to possession -- even
> > though I asked the chairs to take a hum of the room to see if the WG
> > wanted this change. The audio will support me in saying the chairs
> > refused to take this hum (that I asked for). Therefore, it's hard to
> > justify this change when one wasn't agreed to in the room (i.e., by the
> > WG).
> >
> > James
> >
> >
> > >draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
> > >The main issue discussed was getting the right authorization story
> > >into the draft.
> >
> > the irony that this ID doesn't have its "authorization story right"
> > yet draft-ietf-geopriv-dhcp-lbyr-uri-option-07 keeps getting pounded
> > for its authorization story is classic.
> >
> > James
> >
> >
> > >draft-thomson-geopriv-relative-location-00 (Brian Rosen)
> > >The main issue discussed was what to do with the reference point
> > >provided if you don't understand the extension provided by this draft
> > >-- some think that the reference should be used as the location, and
> > >others think that no location should be used. Discussion will continue
> > >on the list.
> > >
> > >draft-george-ecrit-lamp-post-02 (Brian Rosen)
> > >Brian quickly reviewed the addition of CAtypes for lamposts, and the
> > >group discussed moving this as an AD-sponsored draft.
> > >
> > >draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
> > >Martin reviewed how measurements are used in device-aided positioning.
> > >The group discussed different security threats and the lack of decent
> > >mitigations for them.
> > >
> > >Conclusion
> > >The chairs asked for expressions of support for which of the documents
> > >group members would like to see as working group items. Support for
> > >pidf-interior, deref-protocol, relative-location, and held-
> > >measurements was expressed. The plan for moving forward and choosing
> > >an ordering will be discussed on the list.
> > >
> > >
> > >Raw notes from Matt Lepinski and Matt Miller follow:
> > >----------------------------------------------------------------------
> > >GEOPRIV - IETF77
> > >
> > >Notewell
> > >Agenda Bashing
> > >
> > >Doc Status
> > >New RFCs
> > >-civic-address-recommendations: RFC 5774
> > >-l7-lcp-ps: RFC 5687
> > >RFC Ed Queue
> > >-http-location-delivery
> > >-lbyr-requirements
> > >IESG eval
> > >-lis-discovery
> > >-geo-uri
> > >-loc-filters
> > >-prefix
> > >draft-singh-geopriv-pidf-lo-dynamic
> > >
> > >Thank you Cullen Jennings as outgoing AD
> > >BoF location coherence Recap at lunch
> > >* number of protocols out there, how to reconcile them
> > >* draft upcoming
> > >
> > >Status of 3852bis
> > >* no open issues
> > >* number of changes in -08 and -09 (two technical, one editorial)
> > >* Authors believe that the document is ready for WGLC
> > >
> > >Status of Held Identity Extensions
> > >* No open issues
> > >* Authors believe that the document is ready for WGLC
> > >
> > >draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James)
> > >* (martin): more discussions needed, but allowing some points
> > >* no confirmation on some issues
> > >* (martin): intro missing "new to geopriv" info very bad
> > >* chosen authorization model over posession model, need to explain how
> > >the policies are put in place
> > >* the "magic happens" part needs more definition
> > >* there isn't an explaination for how the policy document gets in place
> > >* this is a protocol extension, do we need a p2p protocol to get the
> > >policy in place
> > >* Alissa Cooper: allow for this mechanism to be out of scope, but the
> > >draft needs to reference something that describes a solution
> > >* text to get consensus on the list
> > >* Martin Thompson: struggling with how posession model was rejected,
> > >since others have accepted the limitations
> > >* Brian Rosen: Assumed possession reasonable for DHCP, why not this?
> > >* Hannes to provide text to James for inclusion
> > >* Conclusion: need to add text regarding security issues (possession
> > >or authorization)
> > >
> > >draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
> > >* Henning Schulzrinne: this is a tradeoff between i18n and geomenuing
> > >and the ability to odd delimiations of buildings, and cannot do this
> > >for all possible subdivisions of building identifiers
> > >* In many cases, one knows what a room number looks like regardless of
> > >language and culture
> > >* Rosen: This is necessary if the creator does not know how the user
> > >will use the doc; if printed is ok, but if rendering in a map may not
> > >be acceptable
> > >* Henning Schulzrinne: The administrator knows what rooms are, and
> > >there is no doubt
> > >* Rosen: Acceptable if in document, the semantics are acceptable, then
> > >easy comprimise would be to define the semantics of INT N="Building"
> > >to be the same as the old semantics of BLDG
> > >* Taking discussion to list
> > >* James Winterbottom: For values to be any use, localization is very
> > >important
> > >* Rosen disagrees; XML needs to match pidf
> > >* James Winterbottom: You do not know what to do with data without
> > >localized context
> > >* Chairs table discussion for mailing list (time constraint)
> > >
> > >draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
> > >* Issue with current LIS Discovery using Access Domain from DHCP, is
> > >that it may take a very long time to get deployed (particularly in
> > >residential gateway environments)
> > >* Bernard Aboba: This has been done in may places; trick is to
> > >figuring out where to look in tree, and reverse lookups not useful or
> > >available in practice
> > >* Brian Rosen: Reserse DNS isn't deployed in a lot of very interesting
> > >situations like many DSL deployments
> > >* James Winterbottom: But we have had active participants in this
> > >group who work for DSL providers who have told us that this reserve
> > >tree solution will work in their networks
> > >* Brian Rosen: But my point is that reverse DNS isn't universal
> > >* Ted Hardie: This requires a tie between public IPs vs private NATs,
> > >and assumes there is a mapping between the IP spaces that may not exist
> > >* Bernard Aboba: In the enterprise, the enterprise has one list and
> > >the provider may have another, while in consumer the user doesn't have
> > >a list, and the provider does
> > >* James Winterbottom: The point of this draft is not to replace the
> > >DHCP option. The idea is that you will always try the DHCP option
> > >first and if that works, then you won't use the mechanism in this
> > >draft (reverse DNS)
> > >* Ted Hardie: This draft has a hard tie between the network
> > >architecture and DNS tree, which exist sfor IPv6
> > >* Bernard Aboda: We are going to need to try a number of different
> > >things and see what works (e.g., your local address, what STUN gives
> > >you, etc)
> > >* Ted Hardie: So how does a 3rd party does this, how do I know that
> > >this comes from me or someone else, what about the privacy issues?
> > >Anyone who has my IP address can find the LIS that serves me, isn't
> > >that a problem?
> > >* Ray Bellis: How is anything here not already known?
> > >* Ted Hardie: This expose location-related infromation (e.g., the
> > >physical network that you are attached to) to an observer . Ted is
> > >concerned that the 3rd party issue isn't being seen as important enough
> > >* Peter: The tree climbing is concerning when crossing administrative
> > >boundaries, the octect boundary is arbitrary and is a weakness
> > >* Andy Newton: The desire to go down this route is because DHCP will
> > >take a long time to deploy ... People who run large Reverse DNS space,
> > >don't edit Reverse zones by hand, they use tools which also take a
> > >very long time to update and get deployed. What strikes me as
> > >worrisome, is that you are going to put a lot of query load on people
> > >who have nothing to do with this (especially in the IPv4 case). You
> > >should go to the RIR communities and see what they think abou this.
> > >* Ray Bellis: valid point, and needs to be addressed
> > >* Peter: To make this climbing less ugly, can we determine the current
> > >location lookup be a non-starter?
> > >* James Winterbottom: Where this came from is an interim meeting in
> > >Dallas a few years ago where we talked through a ton of options and
> > >this one was deemed relatively deployable by the people who were
> > >present (which included BT, in the UK)
> > >* Jon Peterson: The document claims that the security concerns are
> > >similar to DHCP and DNS, and this is not quite true. I'd like to see
> > >more discussion of the security/privacy properties of this solution
> > >
> > >draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
> > >* This draft describes a simple profile for derefencing http/s:
> > >location URI
> > >* Cullen Jennings (as an individual): The question has always been how
> > >the authorization works for this. (That is, how the miracle occurs
> > >where the policy information from the rule-maker gets into the server
> > >that is making the authorization decision)
> > >* Martin Thomson: Need to have the discussion. I agree that we need to
> > >have a story in the document. (And maybe that story is "possession
> > >model blah-blah-blah").
> > >* Cullen Jennings: Once we have the story, we can argue about whether
> > >it's the right story.
> > >* Authors request working group adoption. Chairs said there needs to
> > >be a larger working group discussion of what is the next batch of
> > >documents that the group works on.
> > >
> > >draft-thomson-geopriv-relative-location-00 Brian
> > >* Two independent efforts to describe interior location, this draft
> > >combines them
> > >* This draft defines an offset relative to a reference point
> > >* Open Issue: Current version is that if you don't understand the
> > >extension in this draft, then you get the reference point as the
> > >location. Brian and the majority of the authors believe that getting
> > >some location which is mostly right is better than getting no location
> > >at all. A minority of authors believe that you should get nothing (no
> > >location) in the event that you don't understand the extension. (This
> > >minority opinion claims that when the offset is large, giving someone
> > >the reference as the location is worse than giving no location at all).
> > >* Martin Thomson: [Note: Martin supports the minority author opinion
> > >described above] We're here with a new spec, and we're starting off in
> > >the wrong place. You're lying to everyone that looks at this
> > >container. If you include the civic or grml reference, and the client
> > >ignores the location, then you're not getting the right location.
> > >* Marc Linser: 1ts, if we take what you said first, then we wouldn't
> > >be able to extend anything. 2nd, Brian stated we don't declare the
> > >reference point, ...
> > >* Brian: The original draft had an arbitrary string to declare what
> > >the reference point is.
> > >* Jon: Is there any way to declare what the uncertainty is? (That is,
> > >treat it as an impercise location with uncertainty equal to the
> > >magnitude of the offset)
> > >* Brian: This is no way to do that today in civic.
> > >* Martin: In Civic you are not clear (uncertain) about any elemeent,
> > >then you should not include it. (That is, currently in a Civic
> > >uncertainty is implicit in the elements that you choose to include)
> > >* Brian: If you don't understand the extension, you get the reference
> > >and the uncertainty. If you understand the extension, you get a more
> > >precise location
> > >* Brian: There are a number of issues, and we should have a list
> > >discussion.
> > >
> > >(Mini-presentation without slides by Brian Rosen)
> > >draft-george-ecrit-lamp-post-02
> > >* One catype reference about a post that does not include any semantic
> > >numbering
> > >* Another catype reference about a post that does have a significant
> > >numbering
> > >* (unkonwn): If you start to add references to posts, how are these
> > >managed?
> > >* Richard Barnes: Isn't this just a database of locations and an index
> > >into this database. Why don't we just treat it like that
> > >* Henning Schulzrinne: This is common enough that we need to include,
> > >but maybe we need a third type to abstract the posts, but this is good
> > >enough to move forward on. (what we have now covers maybe 80%)
> > >* Suggestion that it might be appropriate to progress this document as
> > >an AD-sponsored draft
> > >
> > >draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
> > >* Draft to describe co-operative positioning between devices (GPS) and
> > >network topology
> > >* Key idea: Devices are in a good position to measure stuff related to
> > >location, but they generally aren't able to turn these measurements
> > >into useful location. (That is, knowing that a device has a round trip
> > >time of X to it's cell tower doesn't do any good without knowing where
> > >the cell tower is). However, if the device sends measurements to a
> > >server that has access to appropriate databases, then the server may
> > >be able to provide more accurate location based on the measurements.
> > >* Ted Hardie: I believe that there is a ton of IPR in this space. The
> > >working group should consider that when trying to decide whether to
> > >step into this space. (patents cover carrying this information, maybe
> > >not over the wire)
> > >* 3 Security Problems
> > >-- Using measurements to get someone elses location without
> > >authorization
> > > + This is easy only if you already know the victim's location
> > > + In many cases it is very difficult to get accurate measurements
> > >for someone else
> > >-- Using measurements to map out someone's network topology
> > > + Similar limitations to the previous problem
> > > + This is at least partially mitigated by rate-limiting queries
> > >from clients
> > > + Much of this topology information is public. If you're going to
> > >broadcast radio, then it's hard to hide the fact that you have network
> > >infrastructure at the point of broadcast origination
> > >-- Using measurements to Indirectly spoof your location (get the
> > >server to lie for you)
> > > + One thing to lie about your own location, another to get someone
> > >else to do that for you
> > > + Meansurements can be spoofed to coerce a LIS to provide false data
> > > + credibility the LIS has in you is gained by the proxy
> > >* What to do about it...
> > >- we don't care
> > > + existing systems trivally spoofed, and no one cares; info used by
> > >targets (navigation aids, etc), so no gain in spoofing
> > >- check inputs
> > > + Measurements checked just as with identifiers (assuming they can
> > >be checked)
> > > + Applies for all three security concerns
> > > + network-based location cannot check every type, would invalidate
> > >or cripple many methods
> > >- Sanity check outputs
> > > + compares result with independent location (e.g. LG location vs.
> > >GPS coords); if location within independent location = probably
> > >location, outside == definitely bad
> > > + limits scope of attacks, doesn't prevent
> > >- Assign blame
> > > + Explicit about location info from untrusted sources
> > > + Could also include verified data (appropriately labeled)
> > > + trust decisions handled by recipients (which can excersize option
> > >1 at their discretion)
> > >* Cullen Jennings: Some other security considerations might be things
> > >like the radio strength on a device
> > >* Alissa Cooper: When you say they're limited by the same mechanisms,
> > >you can make the measurements up. Rate-limited may still help prevent
> > >this.
> > >* Alissa Cooper: Sometimes lying by proxy is a feature not a problem.
> > >* James Winterbottom: I like Option 4 (Assign Blame)
> > >* EKR : The options you present are related to avoiding the lying
> > >issue. But none of your suggestions seem to address the privacy issue
> > >* Martin Thompson: The only way to deal with the privacy issue is to
> > >check the measurements. (or make sure that no one else can obtain the
> > >measurements)
> > >* Cullen Jennings: I'm really pessimistic that our best solutions are
> > >not going to be adequate. This type of information means that we
> > >shouldn't give out the specifics of how we are gaining our location.I
> > >think we need to be realistic about the best we can achieve.
> > >* Alissa Cooper: That you exist means your location can be determined.
> > >* James Winterbottom: The document just needs to clearly explain the
> > >security properties and the limitations of these techniques
> > >* Chiar: Does the working group think that there's a security story
> > >here that with some more work we can understand?
> > >* Ted Hardie: There is a security story and it's depressing.
> > >* EKR: If the best security story is that my...asdfasdfasdfadsf!
> > >
> > >* Matt Lepinski: People are going to do this out in the wild. It would
> > >be better to do this here with the security concerns that exist, than
> > >leave it to the masses to determine it without any concerns
> > >
> > >Discussion of interesting drafts
> > >* relative-location +3
> > >* pidf-interior +2
> > >
> > >Robert AD: Regardless of how many documents the working group adds to
> > >the charter, there needs to be an order.
> > >
> > >_______________________________________________
> > >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
Re: [Geopriv] Minutes from IETF 77
My recollection is that Hannes agreed to provide text, he did not indicate which model he was going to provide text for.
On a slightly different note, I didn't indicate that BT were at the interim meeting in Dallas, I indicated that a BT representative at some time had suggested that the LIS discovery mechanism in the Thomson-Bellis draft would work for the BT network.
Cheers
James
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of James M. Polk
> Sent: Wednesday, 31 March 2010 5:35 AM
> To: Alissa Cooper; geopriv@ietf.org
> Subject: Re: [Geopriv] Minutes from IETF 77
>
> At 10:49 AM 3/30/2010, Alissa Cooper wrote:
> >Minutes - GEOPRIV - IETF 77
> >
> >draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
> >James gave an overview of the most recent changes and the list
> >traffic. The discussion focused on the possession vs. authorization
> >model debate, with Hannes volunteering to provide some possession
> >model text on the mailing list to help resolve the issue.
>
> respectfully - this is incorrect. Hannes volunteered to write some
> text about the authorization model -- which is what's in the doc now.
> If he was to provide possession model text, then the discussion would
> have been very different in the room, as there wasn't a good reason
> to change the existing text from authorization to possession -- even
> though I asked the chairs to take a hum of the room to see if the WG
> wanted this change. The audio will support me in saying the chairs
> refused to take this hum (that I asked for). Therefore, it's hard to
> justify this change when one wasn't agreed to in the room (i.e., by the
> WG).
>
> James
>
>
> >draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
> >The main issue discussed was getting the right authorization story
> >into the draft.
>
> the irony that this ID doesn't have its "authorization story right"
> yet draft-ietf-geopriv-dhcp-lbyr-uri-option-07 keeps getting pounded
> for its authorization story is classic.
>
> James
>
>
> >draft-thomson-geopriv-relative-location-00 (Brian Rosen)
> >The main issue discussed was what to do with the reference point
> >provided if you don't understand the extension provided by this draft
> >-- some think that the reference should be used as the location, and
> >others think that no location should be used. Discussion will continue
> >on the list.
> >
> >draft-george-ecrit-lamp-post-02 (Brian Rosen)
> >Brian quickly reviewed the addition of CAtypes for lamposts, and the
> >group discussed moving this as an AD-sponsored draft.
> >
> >draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
> >Martin reviewed how measurements are used in device-aided positioning.
> >The group discussed different security threats and the lack of decent
> >mitigations for them.
> >
> >Conclusion
> >The chairs asked for expressions of support for which of the documents
> >group members would like to see as working group items. Support for
> >pidf-interior, deref-protocol, relative-location, and held-
> >measurements was expressed. The plan for moving forward and choosing
> >an ordering will be discussed on the list.
> >
> >
> >Raw notes from Matt Lepinski and Matt Miller follow:
> >----------------------------------------------------------------------
> >GEOPRIV - IETF77
> >
> >Notewell
> >Agenda Bashing
> >
> >Doc Status
> >New RFCs
> >-civic-address-recommendations: RFC 5774
> >-l7-lcp-ps: RFC 5687
> >RFC Ed Queue
> >-http-location-delivery
> >-lbyr-requirements
> >IESG eval
> >-lis-discovery
> >-geo-uri
> >-loc-filters
> >-prefix
> >draft-singh-geopriv-pidf-lo-dynamic
> >
> >Thank you Cullen Jennings as outgoing AD
> >BoF location coherence Recap at lunch
> >* number of protocols out there, how to reconcile them
> >* draft upcoming
> >
> >Status of 3852bis
> >* no open issues
> >* number of changes in -08 and -09 (two technical, one editorial)
> >* Authors believe that the document is ready for WGLC
> >
> >Status of Held Identity Extensions
> >* No open issues
> >* Authors believe that the document is ready for WGLC
> >
> >draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James)
> >* (martin): more discussions needed, but allowing some points
> >* no confirmation on some issues
> >* (martin): intro missing "new to geopriv" info very bad
> >* chosen authorization model over posession model, need to explain how
> >the policies are put in place
> >* the "magic happens" part needs more definition
> >* there isn't an explaination for how the policy document gets in place
> >* this is a protocol extension, do we need a p2p protocol to get the
> >policy in place
> >* Alissa Cooper: allow for this mechanism to be out of scope, but the
> >draft needs to reference something that describes a solution
> >* text to get consensus on the list
> >* Martin Thompson: struggling with how posession model was rejected,
> >since others have accepted the limitations
> >* Brian Rosen: Assumed possession reasonable for DHCP, why not this?
> >* Hannes to provide text to James for inclusion
> >* Conclusion: need to add text regarding security issues (possession
> >or authorization)
> >
> >draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
> >* Henning Schulzrinne: this is a tradeoff between i18n and geomenuing
> >and the ability to odd delimiations of buildings, and cannot do this
> >for all possible subdivisions of building identifiers
> >* In many cases, one knows what a room number looks like regardless of
> >language and culture
> >* Rosen: This is necessary if the creator does not know how the user
> >will use the doc; if printed is ok, but if rendering in a map may not
> >be acceptable
> >* Henning Schulzrinne: The administrator knows what rooms are, and
> >there is no doubt
> >* Rosen: Acceptable if in document, the semantics are acceptable, then
> >easy comprimise would be to define the semantics of INT N="Building"
> >to be the same as the old semantics of BLDG
> >* Taking discussion to list
> >* James Winterbottom: For values to be any use, localization is very
> >important
> >* Rosen disagrees; XML needs to match pidf
> >* James Winterbottom: You do not know what to do with data without
> >localized context
> >* Chairs table discussion for mailing list (time constraint)
> >
> >draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
> >* Issue with current LIS Discovery using Access Domain from DHCP, is
> >that it may take a very long time to get deployed (particularly in
> >residential gateway environments)
> >* Bernard Aboba: This has been done in may places; trick is to
> >figuring out where to look in tree, and reverse lookups not useful or
> >available in practice
> >* Brian Rosen: Reserse DNS isn't deployed in a lot of very interesting
> >situations like many DSL deployments
> >* James Winterbottom: But we have had active participants in this
> >group who work for DSL providers who have told us that this reserve
> >tree solution will work in their networks
> >* Brian Rosen: But my point is that reverse DNS isn't universal
> >* Ted Hardie: This requires a tie between public IPs vs private NATs,
> >and assumes there is a mapping between the IP spaces that may not exist
> >* Bernard Aboba: In the enterprise, the enterprise has one list and
> >the provider may have another, while in consumer the user doesn't have
> >a list, and the provider does
> >* James Winterbottom: The point of this draft is not to replace the
> >DHCP option. The idea is that you will always try the DHCP option
> >first and if that works, then you won't use the mechanism in this
> >draft (reverse DNS)
> >* Ted Hardie: This draft has a hard tie between the network
> >architecture and DNS tree, which exist sfor IPv6
> >* Bernard Aboda: We are going to need to try a number of different
> >things and see what works (e.g., your local address, what STUN gives
> >you, etc)
> >* Ted Hardie: So how does a 3rd party does this, how do I know that
> >this comes from me or someone else, what about the privacy issues?
> >Anyone who has my IP address can find the LIS that serves me, isn't
> >that a problem?
> >* Ray Bellis: How is anything here not already known?
> >* Ted Hardie: This expose location-related infromation (e.g., the
> >physical network that you are attached to) to an observer . Ted is
> >concerned that the 3rd party issue isn't being seen as important enough
> >* Peter: The tree climbing is concerning when crossing administrative
> >boundaries, the octect boundary is arbitrary and is a weakness
> >* Andy Newton: The desire to go down this route is because DHCP will
> >take a long time to deploy ... People who run large Reverse DNS space,
> >don't edit Reverse zones by hand, they use tools which also take a
> >very long time to update and get deployed. What strikes me as
> >worrisome, is that you are going to put a lot of query load on people
> >who have nothing to do with this (especially in the IPv4 case). You
> >should go to the RIR communities and see what they think abou this.
> >* Ray Bellis: valid point, and needs to be addressed
> >* Peter: To make this climbing less ugly, can we determine the current
> >location lookup be a non-starter?
> >* James Winterbottom: Where this came from is an interim meeting in
> >Dallas a few years ago where we talked through a ton of options and
> >this one was deemed relatively deployable by the people who were
> >present (which included BT, in the UK)
> >* Jon Peterson: The document claims that the security concerns are
> >similar to DHCP and DNS, and this is not quite true. I'd like to see
> >more discussion of the security/privacy properties of this solution
> >
> >draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
> >* This draft describes a simple profile for derefencing http/s:
> >location URI
> >* Cullen Jennings (as an individual): The question has always been how
> >the authorization works for this. (That is, how the miracle occurs
> >where the policy information from the rule-maker gets into the server
> >that is making the authorization decision)
> >* Martin Thomson: Need to have the discussion. I agree that we need to
> >have a story in the document. (And maybe that story is "possession
> >model blah-blah-blah").
> >* Cullen Jennings: Once we have the story, we can argue about whether
> >it's the right story.
> >* Authors request working group adoption. Chairs said there needs to
> >be a larger working group discussion of what is the next batch of
> >documents that the group works on.
> >
> >draft-thomson-geopriv-relative-location-00 Brian
> >* Two independent efforts to describe interior location, this draft
> >combines them
> >* This draft defines an offset relative to a reference point
> >* Open Issue: Current version is that if you don't understand the
> >extension in this draft, then you get the reference point as the
> >location. Brian and the majority of the authors believe that getting
> >some location which is mostly right is better than getting no location
> >at all. A minority of authors believe that you should get nothing (no
> >location) in the event that you don't understand the extension. (This
> >minority opinion claims that when the offset is large, giving someone
> >the reference as the location is worse than giving no location at all).
> >* Martin Thomson: [Note: Martin supports the minority author opinion
> >described above] We're here with a new spec, and we're starting off in
> >the wrong place. You're lying to everyone that looks at this
> >container. If you include the civic or grml reference, and the client
> >ignores the location, then you're not getting the right location.
> >* Marc Linser: 1ts, if we take what you said first, then we wouldn't
> >be able to extend anything. 2nd, Brian stated we don't declare the
> >reference point, ...
> >* Brian: The original draft had an arbitrary string to declare what
> >the reference point is.
> >* Jon: Is there any way to declare what the uncertainty is? (That is,
> >treat it as an impercise location with uncertainty equal to the
> >magnitude of the offset)
> >* Brian: This is no way to do that today in civic.
> >* Martin: In Civic you are not clear (uncertain) about any elemeent,
> >then you should not include it. (That is, currently in a Civic
> >uncertainty is implicit in the elements that you choose to include)
> >* Brian: If you don't understand the extension, you get the reference
> >and the uncertainty. If you understand the extension, you get a more
> >precise location
> >* Brian: There are a number of issues, and we should have a list
> >discussion.
> >
> >(Mini-presentation without slides by Brian Rosen)
> >draft-george-ecrit-lamp-post-02
> >* One catype reference about a post that does not include any semantic
> >numbering
> >* Another catype reference about a post that does have a significant
> >numbering
> >* (unkonwn): If you start to add references to posts, how are these
> >managed?
> >* Richard Barnes: Isn't this just a database of locations and an index
> >into this database. Why don't we just treat it like that
> >* Henning Schulzrinne: This is common enough that we need to include,
> >but maybe we need a third type to abstract the posts, but this is good
> >enough to move forward on. (what we have now covers maybe 80%)
> >* Suggestion that it might be appropriate to progress this document as
> >an AD-sponsored draft
> >
> >draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
> >* Draft to describe co-operative positioning between devices (GPS) and
> >network topology
> >* Key idea: Devices are in a good position to measure stuff related to
> >location, but they generally aren't able to turn these measurements
> >into useful location. (That is, knowing that a device has a round trip
> >time of X to it's cell tower doesn't do any good without knowing where
> >the cell tower is). However, if the device sends measurements to a
> >server that has access to appropriate databases, then the server may
> >be able to provide more accurate location based on the measurements.
> >* Ted Hardie: I believe that there is a ton of IPR in this space. The
> >working group should consider that when trying to decide whether to
> >step into this space. (patents cover carrying this information, maybe
> >not over the wire)
> >* 3 Security Problems
> >-- Using measurements to get someone elses location without
> >authorization
> > + This is easy only if you already know the victim's location
> > + In many cases it is very difficult to get accurate measurements
> >for someone else
> >-- Using measurements to map out someone's network topology
> > + Similar limitations to the previous problem
> > + This is at least partially mitigated by rate-limiting queries
> >from clients
> > + Much of this topology information is public. If you're going to
> >broadcast radio, then it's hard to hide the fact that you have network
> >infrastructure at the point of broadcast origination
> >-- Using measurements to Indirectly spoof your location (get the
> >server to lie for you)
> > + One thing to lie about your own location, another to get someone
> >else to do that for you
> > + Meansurements can be spoofed to coerce a LIS to provide false data
> > + credibility the LIS has in you is gained by the proxy
> >* What to do about it...
> >- we don't care
> > + existing systems trivally spoofed, and no one cares; info used by
> >targets (navigation aids, etc), so no gain in spoofing
> >- check inputs
> > + Measurements checked just as with identifiers (assuming they can
> >be checked)
> > + Applies for all three security concerns
> > + network-based location cannot check every type, would invalidate
> >or cripple many methods
> >- Sanity check outputs
> > + compares result with independent location (e.g. LG location vs.
> >GPS coords); if location within independent location = probably
> >location, outside == definitely bad
> > + limits scope of attacks, doesn't prevent
> >- Assign blame
> > + Explicit about location info from untrusted sources
> > + Could also include verified data (appropriately labeled)
> > + trust decisions handled by recipients (which can excersize option
> >1 at their discretion)
> >* Cullen Jennings: Some other security considerations might be things
> >like the radio strength on a device
> >* Alissa Cooper: When you say they're limited by the same mechanisms,
> >you can make the measurements up. Rate-limited may still help prevent
> >this.
> >* Alissa Cooper: Sometimes lying by proxy is a feature not a problem.
> >* James Winterbottom: I like Option 4 (Assign Blame)
> >* EKR : The options you present are related to avoiding the lying
> >issue. But none of your suggestions seem to address the privacy issue
> >* Martin Thompson: The only way to deal with the privacy issue is to
> >check the measurements. (or make sure that no one else can obtain the
> >measurements)
> >* Cullen Jennings: I'm really pessimistic that our best solutions are
> >not going to be adequate. This type of information means that we
> >shouldn't give out the specifics of how we are gaining our location.I
> >think we need to be realistic about the best we can achieve.
> >* Alissa Cooper: That you exist means your location can be determined.
> >* James Winterbottom: The document just needs to clearly explain the
> >security properties and the limitations of these techniques
> >* Chiar: Does the working group think that there's a security story
> >here that with some more work we can understand?
> >* Ted Hardie: There is a security story and it's depressing.
> >* EKR: If the best security story is that my...asdfasdfasdfadsf!
> >
> >* Matt Lepinski: People are going to do this out in the wild. It would
> >be better to do this here with the security concerns that exist, than
> >leave it to the masses to determine it without any concerns
> >
> >Discussion of interesting drafts
> >* relative-location +3
> >* pidf-interior +2
> >
> >Robert AD: Regardless of how many documents the working group adds to
> >the charter, there needs to be an order.
> >
> >_______________________________________________
> >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
Re: [Geopriv] Minutes from IETF 77
At 10:49 AM 3/30/2010, Alissa Cooper wrote:
>Minutes - GEOPRIV - IETF 77
>
>draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
>James gave an overview of the most recent changes and the list
>traffic. The discussion focused on the possession vs. authorization
>model debate, with Hannes volunteering to provide some possession
>model text on the mailing list to help resolve the issue.
>Minutes - GEOPRIV - IETF 77
>
>draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
>James gave an overview of the most recent changes and the list
>traffic. The discussion focused on the possession vs. authorization
>model debate, with Hannes volunteering to provide some possession
>model text on the mailing list to help resolve the issue.
respectfully - this is incorrect. Hannes volunteered to write some
text about the authorization model -- which is what's in the doc now.
If he was to provide possession model text, then the discussion would
have been very different in the room, as there wasn't a good reason
to change the existing text from authorization to possession -- even
though I asked the chairs to take a hum of the room to see if the WG
wanted this change. The audio will support me in saying the chairs
refused to take this hum (that I asked for). Therefore, it's hard to
justify this change when one wasn't agreed to in the room (i.e., by the WG).
James
>draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
>The main issue discussed was getting the right authorization story
>into the draft.
the irony that this ID doesn't have its "authorization story right"
yet draft-ietf-geopriv-dhcp-lbyr-uri-option-07 keeps getting pounded
for its authorization story is classic.
James
>draft-thomson-geopriv-relative-location-00 (Brian Rosen)
>The main issue discussed was what to do with the reference point
>provided if you don't understand the extension provided by this draft
>-- some think that the reference should be used as the location, and
>others think that no location should be used. Discussion will continue
>on the list.
>
>draft-george-ecrit-lamp-post-02 (Brian Rosen)
>Brian quickly reviewed the addition of CAtypes for lamposts, and the
>group discussed moving this as an AD-sponsored draft.
>
>draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
>Martin reviewed how measurements are used in device-aided positioning.
>The group discussed different security threats and the lack of decent
>mitigations for them.
>
>Conclusion
>The chairs asked for expressions of support for which of the documents
>group members would like to see as working group items. Support for
>pidf-interior, deref-protocol, relative-location, and held-
>measurements was expressed. The plan for moving forward and choosing
>an ordering will be discussed on the list.
>
>
>Raw notes from Matt Lepinski and Matt Miller follow:
>----------------------------------------------------------------------
>GEOPRIV - IETF77
>
>Notewell
>Agenda Bashing
>
>Doc Status
>New RFCs
>-civic-address-recommendations: RFC 5774
>-l7-lcp-ps: RFC 5687
>RFC Ed Queue
>-http-location-delivery
>-lbyr-requirements
>IESG eval
>-lis-discovery
>-geo-uri
>-loc-filters
>-prefix
>draft-singh-geopriv-pidf-lo-dynamic
>
>Thank you Cullen Jennings as outgoing AD
>BoF location coherence Recap at lunch
>* number of protocols out there, how to reconcile them
>* draft upcoming
>
>Status of 3852bis
>* no open issues
>* number of changes in -08 and -09 (two technical, one editorial)
>* Authors believe that the document is ready for WGLC
>
>Status of Held Identity Extensions
>* No open issues
>* Authors believe that the document is ready for WGLC
>
>draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James)
>* (martin): more discussions needed, but allowing some points
>* no confirmation on some issues
>* (martin): intro missing "new to geopriv" info very bad
>* chosen authorization model over posession model, need to explain how
>the policies are put in place
>* the "magic happens" part needs more definition
>* there isn't an explaination for how the policy document gets in place
>* this is a protocol extension, do we need a p2p protocol to get the
>policy in place
>* Alissa Cooper: allow for this mechanism to be out of scope, but the
>draft needs to reference something that describes a solution
>* text to get consensus on the list
>* Martin Thompson: struggling with how posession model was rejected,
>since others have accepted the limitations
>* Brian Rosen: Assumed possession reasonable for DHCP, why not this?
>* Hannes to provide text to James for inclusion
>* Conclusion: need to add text regarding security issues (possession
>or authorization)
>
>draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
>* Henning Schulzrinne: this is a tradeoff between i18n and geomenuing
>and the ability to odd delimiations of buildings, and cannot do this
>for all possible subdivisions of building identifiers
>* In many cases, one knows what a room number looks like regardless of
>language and culture
>* Rosen: This is necessary if the creator does not know how the user
>will use the doc; if printed is ok, but if rendering in a map may not
>be acceptable
>* Henning Schulzrinne: The administrator knows what rooms are, and
>there is no doubt
>* Rosen: Acceptable if in document, the semantics are acceptable, then
>easy comprimise would be to define the semantics of INT N="Building"
>to be the same as the old semantics of BLDG
>* Taking discussion to list
>* James Winterbottom: For values to be any use, localization is very
>important
>* Rosen disagrees; XML needs to match pidf
>* James Winterbottom: You do not know what to do with data without
>localized context
>* Chairs table discussion for mailing list (time constraint)
>
>draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
>* Issue with current LIS Discovery using Access Domain from DHCP, is
>that it may take a very long time to get deployed (particularly in
>residential gateway environments)
>* Bernard Aboba: This has been done in may places; trick is to
>figuring out where to look in tree, and reverse lookups not useful or
>available in practice
>* Brian Rosen: Reserse DNS isn't deployed in a lot of very interesting
>situations like many DSL deployments
>* James Winterbottom: But we have had active participants in this
>group who work for DSL providers who have told us that this reserve
>tree solution will work in their networks
>* Brian Rosen: But my point is that reverse DNS isn't universal
>* Ted Hardie: This requires a tie between public IPs vs private NATs,
>and assumes there is a mapping between the IP spaces that may not exist
>* Bernard Aboba: In the enterprise, the enterprise has one list and
>the provider may have another, while in consumer the user doesn't have
>a list, and the provider does
>* James Winterbottom: The point of this draft is not to replace the
>DHCP option. The idea is that you will always try the DHCP option
>first and if that works, then you won't use the mechanism in this
>draft (reverse DNS)
>* Ted Hardie: This draft has a hard tie between the network
>architecture and DNS tree, which exist sfor IPv6
>* Bernard Aboda: We are going to need to try a number of different
>things and see what works (e.g., your local address, what STUN gives
>you, etc)
>* Ted Hardie: So how does a 3rd party does this, how do I know that
>this comes from me or someone else, what about the privacy issues?
>Anyone who has my IP address can find the LIS that serves me, isn't
>that a problem?
>* Ray Bellis: How is anything here not already known?
>* Ted Hardie: This expose location-related infromation (e.g., the
>physical network that you are attached to) to an observer . Ted is
>concerned that the 3rd party issue isn't being seen as important enough
>* Peter: The tree climbing is concerning when crossing administrative
>boundaries, the octect boundary is arbitrary and is a weakness
>* Andy Newton: The desire to go down this route is because DHCP will
>take a long time to deploy ... People who run large Reverse DNS space,
>don't edit Reverse zones by hand, they use tools which also take a
>very long time to update and get deployed. What strikes me as
>worrisome, is that you are going to put a lot of query load on people
>who have nothing to do with this (especially in the IPv4 case). You
>should go to the RIR communities and see what they think abou this.
>* Ray Bellis: valid point, and needs to be addressed
>* Peter: To make this climbing less ugly, can we determine the current
>location lookup be a non-starter?
>* James Winterbottom: Where this came from is an interim meeting in
>Dallas a few years ago where we talked through a ton of options and
>this one was deemed relatively deployable by the people who were
>present (which included BT, in the UK)
>* Jon Peterson: The document claims that the security concerns are
>similar to DHCP and DNS, and this is not quite true. I'd like to see
>more discussion of the security/privacy properties of this solution
>
>draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
>* This draft describes a simple profile for derefencing http/s:
>location URI
>* Cullen Jennings (as an individual): The question has always been how
>the authorization works for this. (That is, how the miracle occurs
>where the policy information from the rule-maker gets into the server
>that is making the authorization decision)
>* Martin Thomson: Need to have the discussion. I agree that we need to
>have a story in the document. (And maybe that story is "possession
>model blah-blah-blah").
>* Cullen Jennings: Once we have the story, we can argue about whether
>it's the right story.
>* Authors request working group adoption. Chairs said there needs to
>be a larger working group discussion of what is the next batch of
>documents that the group works on.
>
>draft-thomson-geopriv-relative-location-00 Brian
>* Two independent efforts to describe interior location, this draft
>combines them
>* This draft defines an offset relative to a reference point
>* Open Issue: Current version is that if you don't understand the
>extension in this draft, then you get the reference point as the
>location. Brian and the majority of the authors believe that getting
>some location which is mostly right is better than getting no location
>at all. A minority of authors believe that you should get nothing (no
>location) in the event that you don't understand the extension. (This
>minority opinion claims that when the offset is large, giving someone
>the reference as the location is worse than giving no location at all).
>* Martin Thomson: [Note: Martin supports the minority author opinion
>described above] We're here with a new spec, and we're starting off in
>the wrong place. You're lying to everyone that looks at this
>container. If you include the civic or grml reference, and the client
>ignores the location, then you're not getting the right location.
>* Marc Linser: 1ts, if we take what you said first, then we wouldn't
>be able to extend anything. 2nd, Brian stated we don't declare the
>reference point, ...
>* Brian: The original draft had an arbitrary string to declare what
>the reference point is.
>* Jon: Is there any way to declare what the uncertainty is? (That is,
>treat it as an impercise location with uncertainty equal to the
>magnitude of the offset)
>* Brian: This is no way to do that today in civic.
>* Martin: In Civic you are not clear (uncertain) about any elemeent,
>then you should not include it. (That is, currently in a Civic
>uncertainty is implicit in the elements that you choose to include)
>* Brian: If you don't understand the extension, you get the reference
>and the uncertainty. If you understand the extension, you get a more
>precise location
>* Brian: There are a number of issues, and we should have a list
>discussion.
>
>(Mini-presentation without slides by Brian Rosen)
>draft-george-ecrit-lamp-post-02
>* One catype reference about a post that does not include any semantic
>numbering
>* Another catype reference about a post that does have a significant
>numbering
>* (unkonwn): If you start to add references to posts, how are these
>managed?
>* Richard Barnes: Isn't this just a database of locations and an index
>into this database. Why don't we just treat it like that
>* Henning Schulzrinne: This is common enough that we need to include,
>but maybe we need a third type to abstract the posts, but this is good
>enough to move forward on. (what we have now covers maybe 80%)
>* Suggestion that it might be appropriate to progress this document as
>an AD-sponsored draft
>
>draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
>* Draft to describe co-operative positioning between devices (GPS) and
>network topology
>* Key idea: Devices are in a good position to measure stuff related to
>location, but they generally aren't able to turn these measurements
>into useful location. (That is, knowing that a device has a round trip
>time of X to it's cell tower doesn't do any good without knowing where
>the cell tower is). However, if the device sends measurements to a
>server that has access to appropriate databases, then the server may
>be able to provide more accurate location based on the measurements.
>* Ted Hardie: I believe that there is a ton of IPR in this space. The
>working group should consider that when trying to decide whether to
>step into this space. (patents cover carrying this information, maybe
>not over the wire)
>* 3 Security Problems
>-- Using measurements to get someone elses location without
>authorization
> + This is easy only if you already know the victim's location
> + In many cases it is very difficult to get accurate measurements
>for someone else
>-- Using measurements to map out someone's network topology
> + Similar limitations to the previous problem
> + This is at least partially mitigated by rate-limiting queries
>from clients
> + Much of this topology information is public. If you're going to
>broadcast radio, then it's hard to hide the fact that you have network
>infrastructure at the point of broadcast origination
>-- Using measurements to Indirectly spoof your location (get the
>server to lie for you)
> + One thing to lie about your own location, another to get someone
>else to do that for you
> + Meansurements can be spoofed to coerce a LIS to provide false data
> + credibility the LIS has in you is gained by the proxy
>* What to do about it...
>- we don't care
> + existing systems trivally spoofed, and no one cares; info used by
>targets (navigation aids, etc), so no gain in spoofing
>- check inputs
> + Measurements checked just as with identifiers (assuming they can
>be checked)
> + Applies for all three security concerns
> + network-based location cannot check every type, would invalidate
>or cripple many methods
>- Sanity check outputs
> + compares result with independent location (e.g. LG location vs.
>GPS coords); if location within independent location = probably
>location, outside == definitely bad
> + limits scope of attacks, doesn't prevent
>- Assign blame
> + Explicit about location info from untrusted sources
> + Could also include verified data (appropriately labeled)
> + trust decisions handled by recipients (which can excersize option
>1 at their discretion)
>* Cullen Jennings: Some other security considerations might be things
>like the radio strength on a device
>* Alissa Cooper: When you say they're limited by the same mechanisms,
>you can make the measurements up. Rate-limited may still help prevent
>this.
>* Alissa Cooper: Sometimes lying by proxy is a feature not a problem.
>* James Winterbottom: I like Option 4 (Assign Blame)
>* EKR : The options you present are related to avoiding the lying
>issue. But none of your suggestions seem to address the privacy issue
>* Martin Thompson: The only way to deal with the privacy issue is to
>check the measurements. (or make sure that no one else can obtain the
>measurements)
>* Cullen Jennings: I'm really pessimistic that our best solutions are
>not going to be adequate. This type of information means that we
>shouldn't give out the specifics of how we are gaining our location.I
>think we need to be realistic about the best we can achieve.
>* Alissa Cooper: That you exist means your location can be determined.
>* James Winterbottom: The document just needs to clearly explain the
>security properties and the limitations of these techniques
>* Chiar: Does the working group think that there's a security story
>here that with some more work we can understand?
>* Ted Hardie: There is a security story and it's depressing.
>* EKR: If the best security story is that my...asdfasdfasdfadsf!
>
>* Matt Lepinski: People are going to do this out in the wild. It would
>be better to do this here with the security concerns that exist, than
>leave it to the masses to determine it without any concerns
>
>Discussion of interesting drafts
>* relative-location +3
>* pidf-interior +2
>
>Robert AD: Regardless of how many documents the working group adds to
>the charter, there needs to be an order.
>
>_______________________________________________
>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] WGLC: draft-ietf-geopriv-rfc3825bis-09
This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-rfc3825bis-09
Please send your comments to the list by 13 April 2010. As always,
please remember to send a note in if you've read the document and have
no other comments other than "its ready to go" - we need those as much
as we need "I found a problem."
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
[Geopriv] Minutes from IETF 77
Minutes - GEOPRIV - IETF 77
Summary (prepared by Alissa Cooper):
Chairs' Introduction
The chairs reviewed the status of the WG's documents, noting that
since we have nearly emptied our queue we have space to adopt several
new work items.
draft-ietf-geopriv-rfc3825bis-09 (Bernard Aboba)
Bernard briefly reviewed the changes in -08 and -09. The document
appears ready for WGLC.
draft-ietf-geopriv-held-identity-extensions-03 (Martin Thomson)
Martin indicated that there are no open issues with the document and
that it appears ready for pub request.
draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James Polk)
James gave an overview of the most recent changes and the list
traffic. The discussion focused on the possession vs. authorization
model debate, with Hannes volunteering to provide some possession
model text on the mailing list to help resolve the issue.
draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
Brian reviewed what the INT draft does, and the discussion focused on
the tradeoffs between containers without semantics that cover more
kinds of interior spaces and internationalization/localization. The
discussion moved on to the list.
draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
The discussion of this draft focused on concerns with the tree-
climbing approach and security/privacy issues related to exposing the
IP-to-LIS mapping.
draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
The main issue discussed was getting the right authorization story
into the draft.
draft-thomson-geopriv-relative-location-00 (Brian Rosen)
The main issue discussed was what to do with the reference point
provided if you don't understand the extension provided by this draft
-- some think that the reference should be used as the location, and
others think that no location should be used. Discussion will continue
on the list.
draft-george-ecrit-lamp-post-02 (Brian Rosen)
Brian quickly reviewed the addition of CAtypes for lamposts, and the
group discussed moving this as an AD-sponsored draft.
draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
Martin reviewed how measurements are used in device-aided positioning.
The group discussed different security threats and the lack of decent
mitigations for them.
Conclusion
The chairs asked for expressions of support for which of the documents
group members would like to see as working group items. Support for
pidf-interior, deref-protocol, relative-location, and held-
measurements was expressed. The plan for moving forward and choosing
an ordering will be discussed on the list.
Raw notes from Matt Lepinski and Matt Miller follow:
----------------------------------------------------------------------
GEOPRIV - IETF77
Notewell
Agenda Bashing
Doc Status
New RFCs
-civic-address-recommendations: RFC 5774
-l7-lcp-ps: RFC 5687
RFC Ed Queue
-http-location-delivery
-lbyr-requirements
IESG eval
-lis-discovery
-geo-uri
-loc-filters
-prefix
draft-singh-geopriv-pidf-lo-dynamic
Thank you Cullen Jennings as outgoing AD
BoF location coherence Recap at lunch
* number of protocols out there, how to reconcile them
* draft upcoming
Status of 3852bis
* no open issues
* number of changes in -08 and -09 (two technical, one editorial)
* Authors believe that the document is ready for WGLC
Status of Held Identity Extensions
* No open issues
* Authors believe that the document is ready for WGLC
draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (James)
* (martin): more discussions needed, but allowing some points
* no confirmation on some issues
* (martin): intro missing "new to geopriv" info very bad
* chosen authorization model over posession model, need to explain how
the policies are put in place
* the "magic happens" part needs more definition
* there isn't an explaination for how the policy document gets in place
* this is a protocol extension, do we need a p2p protocol to get the
policy in place
* Alissa Cooper: allow for this mechanism to be out of scope, but the
draft needs to reference something that describes a solution
* text to get consensus on the list
* Martin Thompson: struggling with how posession model was rejected,
since others have accepted the limitations
* Brian Rosen: Assumed possession reasonable for DHCP, why not this?
* Hannes to provide text to James for inclusion
* Conclusion: need to add text regarding security issues (possession
or authorization)
draft-rosen-geopriv-pidf-interior-01 (Brian Rosen)
* Henning Schulzrinne: this is a tradeoff between i18n and geomenuing
and the ability to odd delimiations of buildings, and cannot do this
for all possible subdivisions of building identifiers
* In many cases, one knows what a room number looks like regardless of
language and culture
* Rosen: This is necessary if the creator does not know how the user
will use the doc; if printed is ok, but if rendering in a map may not
be acceptable
* Henning Schulzrinne: The administrator knows what rooms are, and
there is no doubt
* Rosen: Acceptable if in document, the semantics are acceptable, then
easy comprimise would be to define the semantics of INT N="Building"
to be the same as the old semantics of BLDG
* Taking discussion to list
* James Winterbottom: For values to be any use, localization is very
important
* Rosen disagrees; XML needs to match pidf
* James Winterbottom: You do not know what to do with data without
localized context
* Chairs table discussion for mailing list (time constraint)
draft-thomson-geopriv-res-gw-lis-discovery-03 (Ray Bellis)
* Issue with current LIS Discovery using Access Domain from DHCP, is
that it may take a very long time to get deployed (particularly in
residential gateway environments)
* Bernard Aboba: This has been done in may places; trick is to
figuring out where to look in tree, and reverse lookups not useful or
available in practice
* Brian Rosen: Reserse DNS isn't deployed in a lot of very interesting
situations like many DSL deployments
* James Winterbottom: But we have had active participants in this
group who work for DSL providers who have told us that this reserve
tree solution will work in their networks
* Brian Rosen: But my point is that reverse DNS isn't universal
* Ted Hardie: This requires a tie between public IPs vs private NATs,
and assumes there is a mapping between the IP spaces that may not exist
* Bernard Aboba: In the enterprise, the enterprise has one list and
the provider may have another, while in consumer the user doesn't have
a list, and the provider does
* James Winterbottom: The point of this draft is not to replace the
DHCP option. The idea is that you will always try the DHCP option
first and if that works, then you won't use the mechanism in this
draft (reverse DNS)
* Ted Hardie: This draft has a hard tie between the network
architecture and DNS tree, which exist sfor IPv6
* Bernard Aboda: We are going to need to try a number of different
things and see what works (e.g., your local address, what STUN gives
you, etc)
* Ted Hardie: So how does a 3rd party does this, how do I know that
this comes from me or someone else, what about the privacy issues?
Anyone who has my IP address can find the LIS that serves me, isn't
that a problem?
* Ray Bellis: How is anything here not already known?
* Ted Hardie: This expose location-related infromation (e.g., the
physical network that you are attached to) to an observer . Ted is
concerned that the 3rd party issue isn't being seen as important enough
* Peter: The tree climbing is concerning when crossing administrative
boundaries, the octect boundary is arbitrary and is a weakness
* Andy Newton: The desire to go down this route is because DHCP will
take a long time to deploy ... People who run large Reverse DNS space,
don't edit Reverse zones by hand, they use tools which also take a
very long time to update and get deployed. What strikes me as
worrisome, is that you are going to put a lot of query load on people
who have nothing to do with this (especially in the IPv4 case). You
should go to the RIR communities and see what they think abou this.
* Ray Bellis: valid point, and needs to be addressed
* Peter: To make this climbing less ugly, can we determine the current
location lookup be a non-starter?
* James Winterbottom: Where this came from is an interim meeting in
Dallas a few years ago where we talked through a ton of options and
this one was deemed relatively deployable by the people who were
present (which included BT, in the UK)
* Jon Peterson: The document claims that the security concerns are
similar to DHCP and DNS, and this is not quite true. I'd like to see
more discussion of the security/privacy properties of this solution
draft-winterbottom-geopriv-deref-protocol (Martin Thomson)
* This draft describes a simple profile for derefencing http/s:
location URI
* Cullen Jennings (as an individual): The question has always been how
the authorization works for this. (That is, how the miracle occurs
where the policy information from the rule-maker gets into the server
that is making the authorization decision)
* Martin Thomson: Need to have the discussion. I agree that we need to
have a story in the document. (And maybe that story is "possession
model blah-blah-blah").
* Cullen Jennings: Once we have the story, we can argue about whether
it's the right story.
* Authors request working group adoption. Chairs said there needs to
be a larger working group discussion of what is the next batch of
documents that the group works on.
draft-thomson-geopriv-relative-location-00 Brian
* Two independent efforts to describe interior location, this draft
combines them
* This draft defines an offset relative to a reference point
* Open Issue: Current version is that if you don't understand the
extension in this draft, then you get the reference point as the
location. Brian and the majority of the authors believe that getting
some location which is mostly right is better than getting no location
at all. A minority of authors believe that you should get nothing (no
location) in the event that you don't understand the extension. (This
minority opinion claims that when the offset is large, giving someone
the reference as the location is worse than giving no location at all).
* Martin Thomson: [Note: Martin supports the minority author opinion
described above] We're here with a new spec, and we're starting off in
the wrong place. You're lying to everyone that looks at this
container. If you include the civic or grml reference, and the client
ignores the location, then you're not getting the right location.
* Marc Linser: 1ts, if we take what you said first, then we wouldn't
be able to extend anything. 2nd, Brian stated we don't declare the
reference point, ...
* Brian: The original draft had an arbitrary string to declare what
the reference point is.
* Jon: Is there any way to declare what the uncertainty is? (That is,
treat it as an impercise location with uncertainty equal to the
magnitude of the offset)
* Brian: This is no way to do that today in civic.
* Martin: In Civic you are not clear (uncertain) about any elemeent,
then you should not include it. (That is, currently in a Civic
uncertainty is implicit in the elements that you choose to include)
* Brian: If you don't understand the extension, you get the reference
and the uncertainty. If you understand the extension, you get a more
precise location
* Brian: There are a number of issues, and we should have a list
discussion.
(Mini-presentation without slides by Brian Rosen)
draft-george-ecrit-lamp-post-02
* One catype reference about a post that does not include any semantic
numbering
* Another catype reference about a post that does have a significant
numbering
* (unkonwn): If you start to add references to posts, how are these
managed?
* Richard Barnes: Isn't this just a database of locations and an index
into this database. Why don't we just treat it like that
* Henning Schulzrinne: This is common enough that we need to include,
but maybe we need a third type to abstract the posts, but this is good
enough to move forward on. (what we have now covers maybe 80%)
* Suggestion that it might be appropriate to progress this document as
an AD-sponsored draft
draft-thomson-geopriv-held-measurements-05 (Martin Thomson)
* Draft to describe co-operative positioning between devices (GPS) and
network topology
* Key idea: Devices are in a good position to measure stuff related to
location, but they generally aren't able to turn these measurements
into useful location. (That is, knowing that a device has a round trip
time of X to it's cell tower doesn't do any good without knowing where
the cell tower is). However, if the device sends measurements to a
server that has access to appropriate databases, then the server may
be able to provide more accurate location based on the measurements.
* Ted Hardie: I believe that there is a ton of IPR in this space. The
working group should consider that when trying to decide whether to
step into this space. (patents cover carrying this information, maybe
not over the wire)
* 3 Security Problems
-- Using measurements to get someone elses location without
authorization
+ This is easy only if you already know the victim's location
+ In many cases it is very difficult to get accurate measurements
for someone else
-- Using measurements to map out someone's network topology
+ Similar limitations to the previous problem
+ This is at least partially mitigated by rate-limiting queries
from clients
+ Much of this topology information is public. If you're going to
broadcast radio, then it's hard to hide the fact that you have network
infrastructure at the point of broadcast origination
-- Using measurements to Indirectly spoof your location (get the
server to lie for you)
+ One thing to lie about your own location, another to get someone
else to do that for you
+ Meansurements can be spoofed to coerce a LIS to provide false data
+ credibility the LIS has in you is gained by the proxy
* What to do about it...
- we don't care
+ existing systems trivally spoofed, and no one cares; info used by
targets (navigation aids, etc), so no gain in spoofing
- check inputs
+ Measurements checked just as with identifiers (assuming they can
be checked)
+ Applies for all three security concerns
+ network-based location cannot check every type, would invalidate
or cripple many methods
- Sanity check outputs
+ compares result with independent location (e.g. LG location vs.
GPS coords); if location within independent location = probably
location, outside == definitely bad
+ limits scope of attacks, doesn't prevent
- Assign blame
+ Explicit about location info from untrusted sources
+ Could also include verified data (appropriately labeled)
+ trust decisions handled by recipients (which can excersize option
1 at their discretion)
* Cullen Jennings: Some other security considerations might be things
like the radio strength on a device
* Alissa Cooper: When you say they're limited by the same mechanisms,
you can make the measurements up. Rate-limited may still help prevent
this.
* Alissa Cooper: Sometimes lying by proxy is a feature not a problem.
* James Winterbottom: I like Option 4 (Assign Blame)
* EKR : The options you present are related to avoiding the lying
issue. But none of your suggestions seem to address the privacy issue
* Martin Thompson: The only way to deal with the privacy issue is to
check the measurements. (or make sure that no one else can obtain the
measurements)
* Cullen Jennings: I'm really pessimistic that our best solutions are
not going to be adequate. This type of information means that we
shouldn't give out the specifics of how we are gaining our location.I
think we need to be realistic about the best we can achieve.
* Alissa Cooper: That you exist means your location can be determined.
* James Winterbottom: The document just needs to clearly explain the
security properties and the limitations of these techniques
* Chiar: Does the working group think that there's a security story
here that with some more work we can understand?
* Ted Hardie: There is a security story and it's depressing.
* EKR: If the best security story is that my...asdfasdfasdfadsf!
* Matt Lepinski: People are going to do this out in the wild. It would
be better to do this here with the security concerns that exist, than
leave it to the masses to determine it without any concerns
Discussion of interesting drafts
* relative-location +3
* pidf-interior +2
Robert AD: Regardless of how many documents the working group adds to
the charter, there needs to be an order.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Subscribe to:
Posts (Atom)