Re: [Geopriv] Minutes from IETF 77

["James M. Polk" <[e-mail]>]

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/geopriv