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 possession  
model 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 (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.