Re: [Geopriv] Minutes from IETF 77

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

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.

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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of James M. Polk
> > Sent: Wednesday, 31 March 2010 5:35 AM
> > To: Alissa Cooper; [e-mail]
> > 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
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv