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 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. At some point in the past, a BT representative had suggested that the LIS discovery mechanism in the Thomson-Bellis draft would work for the BT network. * 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.