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.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
