Re: [Geopriv] Minutes from IETF 77
Alissa Cooper <acooper@cdt.org> Tue, 30 March 2010 19:49 UTC
Return-Path: <acooper@cdt.org>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976E03A690C for <geopriv@core3.amsl.com>; Tue, 30 Mar 2010 12:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.447
X-Spam-Level:
X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgif+7iNSLME for <geopriv@core3.amsl.com>; Tue, 30 Mar 2010 12:49:46 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 5131B3A68C8 for <geopriv@ietf.org>; Tue, 30 Mar 2010 12:49:45 -0700 (PDT)
Received: from [10.0.1.112] ([207.188.255.130]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 30 Mar 2010 15:50:05 -0400
Message-Id: <7B43D427-5E01-4AB6-B187-5813CB017535@cdt.org>
From: Alissa Cooper <acooper@cdt.org>
To: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <201003301834.o2UIYuG8007320@sj-core-3.cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 30 Mar 2010 15:50:04 -0400
References: <8677CCB7-C867-478D-9296-1B1B1F348366@cdt.org> <201003301834.o2UIYuG8007320@sj-core-3.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Minutes from IETF 77
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2010 19:49:50 -0000
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. 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] Minutes from IETF 77 Alissa Cooper
- Re: [Geopriv] Minutes from IETF 77 James M. Polk
- Re: [Geopriv] Minutes from IETF 77 Winterbottom, James
- Re: [Geopriv] Minutes from IETF 77 James M. Polk
- Re: [Geopriv] Minutes from IETF 77 Alissa Cooper