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