[Geopriv] IETF 78 Draft Minutes

["Richard L. Barnes" <[e-mail]>]

Draft minutes below, please send comments by the end of the week.
--Richard


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.