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
