Minutes - GEOPRIV - IETF 78 Summary (prepared by Richard Barnes): Chairs' Introduction The chairs briefly reviewed document status. Alissa Cooper called for more feedback on Roberts comments on draft-ietf-geopriv-arch draft-ietf-sipcore-location-conveyance (James Polk) New version includes significant simplifications. Further revisions will follow based on SIPCORE discussions. Major open issue is how to handle GEO URIs. draft-ietf-geopriv-dhcp-lbyr-uri-option (James Polk) New version out today incorporates new privacy text, and should be ready for WGLC. Chairs will issue WGLC soon. draft-barnes-hard-problem (Richard Barnes) Raising awareness of High Assurance Redirection problem, related to secure service delegation via the DNS. Contact Richard Barnes or Peter Saint-Andre if interested. draft-ietf-geopriv-held-measurements (Martin Thomson) Current draft has updated security considerations. Needs more review before publication, both from a security perspective and with regard to the individual measurement elements. draft-ietf-geopriv-deref-protocol (Martin Thomson) Privacy concerns remain, since there's no current mechanism for managing access control policies. Proposal to add a GET-based deref mechanism was thouroughly debated, with several attendees expressing a preference for having only one mechanism (GET or POST). draft-ietf-geopriv-relative-location (Brian Rosen) Current document is essentially the same as the last. No objections in the room to the current approach. Agreement that document will reference the relevant IEEE 802 spec as a motivation for the TLV formats. draft-thomson-geopriv-res-gw-lis-discovery (Ray Bellis) Continuing security and privacy issues, including an instance of the HARD problem and concern over exposing location servers. Discussion will continue on the list. draft-george-geopriv-lamp-post (Brian Rosen) Basically no change from last time. There was discussion of alternative, more general approaches, but ultimately the group preferred a more specific approach. draft-barnes-geopriv-policy-uri (Richard Barnes) Mechanism to allow clients to control policy on location URIs. Hannes Tschofenig noted possible efficiency gains could result from just including policy in a HELD transaction. Strong consensus to work on the problem, but there will be further discussion of efficiency concerns before adoption. Martin Thomson raised an issue with draft-ietf-geopriv-policy, where the current location fuzzing algorithm can cause a moving target's location to be exposed more precisely. The authors will work to correct the algorithm. Brian Rosen made a proposal to re-design the format for civic addresses, moving to a more generic type/value format. Participant opinions varied widely, and discussion will continue on the list. Raw minutes from Adam Roach follow ---------------------------------- GEOPRIV - July 18, 2010 @ 1300 Introduction - Chairs ===================== * Agenda bash, chairs (see slides) - Martin Thomson: Asks for fewer than 20 minutes for LIS discovery, suggests timeslot at end for GEOPRIV policy - Chairs agree to "credit forward" any unused time from LIS discovery * Document status review, chairs (see slides) * Call from chairs to comment on architecture doc in IETF LC sipcore-location-conveyance - James Polk ======================================== * Summary of changes to document (see slides) (see also SIPCORE minutes) - James asks room for any objections to the various decisions made in SIPCORE session regarding the document. None registered. - Cullen: looks like the same people in the room; the comments & complaints should be the same. DHCP Location by reference URI option- James Polk ================================================= * Summary of changes (see slides) - Chairs: Only outstanding issue was addressing privacy considerations, which is addressed in -08 - Martin Thomson: We agreed to remove "version" and "removed" tags. They aren't needed with suboptions. James thinks this change can be collected in with WGLC - Chairs: document to be WGLC soon. The HARD Problem -- Chairs ========================== * See slides for summary of problem - Encourage participants to contact Richard Barnes and/or Peter St. Andre for further details and feedback HELD Measurements - Martin Thomson ================================== * Document Status (see slides) - Author call for feedback on WiFi measurement procedure changes * Security Updates (see slides) - Author call for feedback on new security text (list reviews have been sparse on the topic so far). - Hannes Tschofennig: Agrees that the security story is unsurprising and a little depressing. - Martin: The idea of a supporting observation is that a device provides a measurement (without any protection from spoofing), and the LIS has the ability to request proof of the measurement, then a greater degree of assurance is possible. - Alissa: Can you give an example? - Martin: For example, if a cell ID is provided, the LIS might request information relating to the radio output of that cell ID at the moment. * Remaining work (see slides) - Cullen Jennings: Splitting up the document to prevent IPR disclosures from disrupting the whole mechanism is a simple means to do so. The cost of doing so is very low. - Gabor: The measurements section is not in agreement with ??? -- the round trip time, for example. For delivering BSSID, there is a suggestion that APs can sign their mac address to provide better reliablity. - Martin: It would be great if you could put those points on the list. - Chairs: Input from IEEE and 3GPP would be great. - Chairs: Do people think the security sections are accurate and comprehensive? [Note the presence of nods from the room] Deref protocol - Martin Thompson ================================ * Status Update (see slides) - Cullen: Likes the text in the draft. Is concerned that the security is based on "you will do something, but don't have any normative statements about how." Worried that it's not mandatory to implement a security scheme in a client that can be assured to be in a server. - Hannes: The concern is that there's no mandatory-to-implement security mechanism. You need to have bilateral agreements between the client and the server to ensure security. - Cullen: For example, there's no way to specify an ACL. It gives examples of how it can be done, but nothing that is guaranteed to be there. - Martin: When we say "possession model," it is a mechanism for doing this. Not a good one, but one nonetheless. - Hannes: It would be difficult to say that this document needs to solve this problem, when other documents haven't been required to do so. - Cullen: Yes, many documents have this problem. I don't think we are in line with our charter -- we need to do privacy as an integral part of the protocol, not bolt it on later. - Alissa: NENA tests have been using possession model for this purpose. - Hannes: (missed some comments here about the use of OAUTH). - Richard: propose an extension for identity-based access controls. - Hannes: No, it's not the same. If someone comes along from an OAUTH token, that's a very different thing than coming in with HTTP Digest authentication. - Marc: Agree with Cullen -- we understand the posession model, but we're not really ready to embrace it without other security. - Randy Gellens: The purpose of GEOPRIV is to make sure we don't forget to include privacy at the beginning. Also, as a possible partial solution: LEMONADE came up with a "pawn ticket URL" approach in which the URL includes a role restriction. For example, "this URL can only be derigetered by a user the server trusts." We might consider something similar, e.g.: "this URI can be resolved only by something the LIS trusts, like a PSAP or a call router." That fits in well with the NENA model. This would provide at least more than we have now. - Hannes: Any IPR on this mechanism? - Randy: Not aware of any. - Hannes: Does about the same thing as posession. * Issue: HTTP GET Requests (see slides for summary) - Cullen: It's better to return an error. The client has done something that the protocol didn't expect. In this case, it would be better for things to fail, than for them to succeed in the wrong way. - Martin: The rationale for using POST instead of GET is because normal usage might not be idempotent. But in deref, idempotence is guaranteed, so there's no harm. - Alex Mayerhofer: If you deal with GET, you also need to consider the other HTTP methods. Also, keep in mind that POST usually changes something on the server, while GET should not. - Brian: If we decide GET is *the* way to do this, then that's fine. But right now we say POST is the mechanism. We don't need two mechanisms for the same thing. If you do this mechanism, then you've done POST. If you don't, then you can't make sense of what happend for GET. - Alex: You want to add caching considerations. - Cullen: It's not clear that this is idempotent. If it's one-time use, then it's not. - Martin: We don't have that concept. - Cullen: but we need one to make sure that the possession model works. - Martin: But how can you make sure you know the user got what they needed? - [Whole working group talking at once] - Richard Barnes (at floor mic): Why are we using HELD in the first place? It's so we can send parameters (e.g. geodetic versus civic). The GET could be a simplified interface. - Adam Roach: Just pick one. - Brian Rosen: I'm okay with GET. You can get what you need with GET. - Richard: We started out with POST because that's what HELD used. But a lot of the document says "don't do what HELD says." So, if all we want is a small number of parameters, then... - Martin: We might need this to be extensible. - Richard: As long as it fits into key/value, it can go into a query string. - Jon: I worry that if we shave this down to the query string, then we back ourselves into a corner, and end up with something that is not as future proof. - Martin: Take it to the list. - Jonathan Lennox: Making it GET makes the caching properties come back into play. This could be useful, and could be dangerous. Relative Location - Brian Rosen =============================== * No significant updates since Anaheim (see slides). * Major open issue: what to do if you don't understand the extension? (see slides) - Martin Thomson: Thought we discussed & closed the topic. The resolution is already in the draft. - Brian: If Martin is happy with what's in the document, then I'm happy. * To Do (see slides) - Martin: We need to define the bucket that all the bits go in. 802.11v has defined a bucket, and they're one of the key consumers of this work. We can define our own bucket -- do we need to? - Brian: And should we do it in this draft? I'm bothered that we don't have a bucket, but don't think it goes here. - Martin: So, if 802.11v has what they need, can we kill the binary parts? - Everyone: No, 802.11v cites this document. - Dorthy: The goal is to have an IETF document that everyone can use. The copy of data into 802.11v is a failsafe in case the IETF work doesn't complete. - Brian: So, should the IETF define the bucket? - Dorthy: It's hard to speak for the whole group. Personally, it would be nice to have, but not critical. - Geoff Thompson: Is there text in 802.11v that says this text goes away? - [some disagreement here -- Geoff and Dorthy to work offline to reach conclusion] - Richard: Would it make sense to reference the 802.11v bucket? - Brian: No objection. - Martin: Just looking for something a bit more concrete than the current situation. - Marc: Clearly, in 802.11v, the container is DHCP. Semantically, it makes no sense to put relative location in DHCP. - Dorthy: Agree with Marc's comments. If we need an official response on a specific question, would be happy to get that answer for GEOPRIV. - Brian: Would there be an objection to referencing the 802.11v informatively as an example? - Dorthy: No, as long as it can be used in other buckets as well. ************************************************************************* * Compromise: the REL LOC document will informatively reference the 802 * * document as an *example* of how these TLVs can be used. * ************************************************************************* res-gw lis discovery draft - Ray Bellis ======================================= * Query for WG adoption (see slides) - Richard Barnes: We need to make sure we know that there can be a good security & privacy story before we adopt the document. There are also some IPv6 concerns. Think we need to know that there is *some* story that can be told before we adopt. - Hannes: Lots of the text is repeated from other documents about things like Layer 7 LCP. Relating to a previous meeting: the fundamental problem is that you don't get DHCP to the endpoints becuase intermediaries don't understand the extension. Have there been investigations about how large this problem might be? - Ray: Not with respect to the specific mechanism. Have seen just about no home gateways that let arbitrary DHCP options through. - Hannes: So how about PPP extensions? - Ray: We tried. - Cullen: With regard to the "tree climing" problem, consider that typing, e.g., "Cisco" into a URL bar for a browser will result in 4 or 5 queries. It hasn't broken DNS yet. [ Some comment I didn't understand about IPv6 and certain prefixes ] - Martin: Think we can address tree climing concerns. Think we can address privacy concerns (although it will be a challenge). We have the same kinds of problems in WGs like ALTO. Having a good description of the problem would help progress. - Ray: In 3rd party case -- privacy is addresses by 3rd parties having bilateral agreements with LIS. - Richard: Isn't that true for advertising partners also? - Hannes: Perhaps DNS isn't the right mechanism. Things like anycast. Yes, it wouldn't support 3rd party queries, but that might be better. Have concerns that 3rd party queries would be used outside of emergency contexts. - Jon: Yes, we could document the shortcomings, but the shortcomings are catastrophic. There must be some way that we can do 1st party in a way that you're communicating to the access network only from within the access network. DHCP provides this. We need something similar. - Martin: that's a bit of an exaggeration. You can find the server, not the actual location. - Jon: If there were a good authorization model for the 3rd party case, then you can have a good solution. But aside from the emergency case, any valid authorizaiton model is hard to beleive. - Ray: The ISP could respond to queries from anywhere, or have ACLs for who queries. - Jon: We really need to have a better description around the requirements for the solution before we can move forward. - Chairs: Sounds like we need to keep talking about this, and possibly consider other mechanisms. We should take the discussion to the list. Lamp-Post - Brian Rosen ======================= * Adds two civic address fields (CA types) to PIDF-LO (see slides) * Open Issue: two different CA types. Can we unify them and include other kinds of posts? (see slides) - Martin: Could we add this on with prefix? - Brian: Prefix has gone through. - Roger Marshall: How about call boxes, manhole covers? - Brian: The question is whether these are customarily used to locate things. You'll say things like "I'm on I-10, milepost 78". - Hannes: So how does this work? Usually you get PIDF-LO from a server. But you're talking about things that the user would provide, like lamp-posts. - Brian: Right now, it's just a CA. The question is: if you pass a lamp-post, and that's the only location you pass, is that a valid query? The answer for a lamp-post is "yes." - Hannes: But how does it get in the device in the first place? - Brian: A good example is a train -- it will provide location by milepost. - Richard: I'm concerned, though, that there are tons of numbered things out there. It would be nice if we could do this without updating the XML schema each time. - Geoff: this is an element of linear addressing along a path. - Brian: True for mileposts, not necessarily for lampposts. - Geoff: Stuff that is arbitrarily numbered across a 2D space... are we adequately differentiating those? - Brian: For the existing draft we sure are. - Roger Marshall: This is too specific. We need to find something like a grid that these can fit into. In terms of where this comes from, we could have a reverse lookup on lat/long. - Martin: Or it could come from RFID, or barcodes, etc. - Richard: Or smart roads. - Martin: I agree that we want a better abstraction for these kinds of things. - Hannes: Don't you need a registry? - Brian: You need to know that it is a lamp post. - Hannu: Are we talking about distance from some known point? - Brian: No, it's an identifier for the lamp post. - Keith Drage: So, with the canal example, you have (for examples) bridges and locks. You have to know which one you're talking about. - Martin: It looks like a registry just masks the problem. If we attempt to develop a taxonomy, we'll take forever. So, let people establish their own schemes for disambiguation, and local name spaces. If they need to number lampposts in China, then they can use local convention for differentiating number schemes. - Brian: That works as long as instructions for encoding addresses in a specific country have a list of valid values for this kind of thing. - Cullen: It's not like we have hundreds of thousands of these things. If we make it open-ended, then the chance you'll have to do manual entry or normalization goes way up. We have two things in front of us, let's just standardize them. - Alex: Concerned that we're adding CA types to PIDF-LO without already having everything defined for every known system - Alex: We need to keep in mind what happens when you have conflicts between CA types -- some kind of priority among them. - Chairs: Is this a problem that needs a solution? Do we need a document to be able to address these two numbered things (lamp posts, mile markers) - Geoff: Originally, I wanted more complexity, but now think we should do these two, and maybe add more in the future. *************************************************************************** Chair call for hums: Should we work on this kind of thing? *********************************************************** *** Wide agreement that we need to work on this problem *** *********************************************************** Should we focus on these two issues? [versus] Should we make a more general solution? ******************************************************************** *** Some hums on both sides, with a bias for a specific solution *** ******************************************************************** *************************************************************************** Geopriv policy URI - Richard Barnes =================================== * Motivation (see slides) * Mechanism description (see slides "Provide a control channel", "Accessing the control channel", "Complexity") * Next steps? - Hannes: This relates to HELD and DHCP -- namely, how one gets these references. Also, how does one get the format for this policy? Is it useful to have a separate protocol mechanism to convey this information? What this means is that, when you get location, you need to do another transaction. So, why don't we do this in-band? And, if we don't want to do it in-band (e.g. DHCP), then why don't we do what we previously worked on (XCAP)? Or using WEBDAV? - Richard: You can view this as using a very simple profile of XCAP or WEBDAV. - Hannes: How would this work in the situation that other people can see the policy URL? - Richard: You use HTTPS, just like HELD says. For DHCP, you need to rely on link security. - Cullen: This is clever. You split the posession model for the 1st party, and a non-posession model for the 3rd party. Not terribly fond of XCAP. - Martin: We have a patch operation for HTTP that makes XCAP unnecessary. - Marc: We need to go to HELD an DHCP LbyR to reflect the security requirements. - Hannes: HELD was much more efficient at this. - Martin: Really, I don't care. - Hannes: Security is one issue. But if you have multiple choices, you have to know which one to pick. - Martin: We need to determine whether ACL whitelist policies is what we need. This is specific to deref. - Richard: This gives a control channel for putting permission on location deref. There's a different question about authenticating the asking entities, but that's the deref draft. - Martin: But is this a requirement? I think I'm hearing that it is. WRT performance, was thinking about an extension that would help with performance. - Hannes: In HELD, you do an HTTP exchange and get the location. You then shuffle the policy along with at the same time, versus doing a completely separate protocol exchange. - Martin: So the suggestion is that we add a mechanism to add the policy to the location request, as an optimization. Chair query: should the WG take this work on? ************************************************ *** Unanimous support for taking the work on *** ************************************************ - Chair: recommend addressing the performance issue on the list, and then will call for consensus on adoption. Location obsfucation - Martin Thomson ===================================== * Read the mailing list, there's a link to a useful image in there. * Short summary: creation of a new circle when location obsfucation is in effect can reveal lots of information about actual locaion. Need to come up with a way to generate new circles. Heresy - Brian Rosen ==================== * Adding a new CA type requires us to define a new schema. * Suggest redefining civic address, with backwards compatibility, such that we have a single element that has a "type/value" indication. - Jon Peterson: Probably a good idea to fix this. - Alex: This does add flexibility in adding new things, but also adds great flexibility in how things can go wrong. Plus, you're pretty much devolving to key/value. - Richard: We're pretty much already at key/value, but with the complexity of XML. If we have to break compatibility to do things, then let's do that now. - Adam: Will RELAX NG fix this? - Brian: We asked XML experts, and they don't think so. - Chairs: Continue offline or on-list. We're out of time.