Subject: RE: [Geopriv] draft-winterbottom-location-uri-00

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Jul 2005 20:01:00 -0400

> In a quick read, I have one comment and the following questions.....

>From your reading, it has become apparent to me that the draft needs to create a finer distinction between location provisioning by-reference and location conveyance by-reference; there are certainly places where it uses arguments about conveyance to say things about provisioning without sufficiently distinguishing the two cases. That's important feedback.

Also, it's pretty clear that the text uses 'generator' in a few places to refer to an administrative domain that can generate and distribute location information, which is a rather misleading usage of the term that needs to be remedied.

> The draft never discusses the privacy issues as outlined in RFC3693 and the
> GeoPriv charter.

The draft is a -00 that floats the concept of location provisioning by-reference. It is not specific proposal for a mechanism. Clearly more detailed treatment of requirements would be necessary before any proposal would be advanced. However, I don't envision any major roadblocks along those lines; some more specific responses on privacy below will spell out why.

> 1) "Similarly a query response mechanism of this nature moves towards
> providing better location currency, and because the location is provided
> directly from the location generator the dependability of the location is of
> a higher degree also."
> 
> Does 'directly from the location generator' imply such a service at all
> access port devices?  Could you explain the higher degree of dependability?

A location generator is the component in the GEOPRIV architecture that manufactures PIDF-LO documents and begins the GEOPRIV lifecycle. It is not bound to any specific network component like an access device or an endpoint. However, I do agree that the cited statement is technically incorrect; it should be 'directly from the location server', as opposed to 'tunneled through an endpoint'. The location generator component has no logical association with recipients in the GEOPRIV architecture.

"Dependability" in this context means something closer to "assurance" or "trust". Basically, this text looks forward to the arguments for location -conveyance- by-reference. The point this is trying to make is that any uncertainty or unreliability that might be introduced in the system by using the endpoint as a middleman between the generator and the recipient can be reduced if location is conveyed by-reference.

> 2) "Location references support session decoupling by allowing the end-point
> to distribute the location reference to third parties so that they may
> obtain the end-point's location without the end-point needing to maintain a
> session with the third party."
> 
> How does this protect the privacy of the end-user in accordance with both
> the GeoPriv charter and RFC-3693?

I begin to sense that this will be a point we'll all need to talk about for a bit. If you look at the geopriv architecture, the rule-maker inserts rules into a logical entity, the location server, which might or might not be instantiated jointly with a location generator. The logical point of policy enforcement has never been the client's endpoint. Privacy is a function that is logically relegated to the entity that distributes location information to recipients.

Whether or not location information ever traverses an endpoint I control has nothing to do with whether or not my policies are enforced. Why would it? The location server, wherever it is instantiated, has that responsibility.

> 3) "Furthermore, some generators of location information might not want to
> disclose this information directly to endpoints for various business-model
> reasons, but might be perfectly willing to give this information to trusted
> requestors."
> 
> Same privacy issues as above.  

Same response as above.

GEOPRIV never assumed that the LG was under end-user control. In fact, I think it assumed that commonly it would not be. It assumed that in many cases LGs would be controlled by various sorts of service providers. 

Policies developed by a rule-maker (end user) come into play at the point that location information is shared with recipients. My ability to express and publish my policies to location servers has nothing to do with whether or not other policies enable me to receive my own location information. Multiple independent rule-makers (like me and my service provider) may input rules relevant to the same target (me). Those policies need to be combined and composed into a coherent logical pictures of the policies associated with me.

> Plus, please expand on the idea that a
> location generator may withhold information pertaining to an end-point from
> the end-point?  Business reason (holding location information hostage for
> money)?

I am being held hostage in this fashion by all of my wireless providers at this moment, as are many of the people reading this mail, I suspect.

> 4) "Continually or periodically re-measuring the location of each end-point
> and then notifying or pushing this new location to the end-point is
> expensive and generally unnecessary."
> 
> To this point, I thought Location URI is a proposed conveyance mechanism.
> Please explain how a 3rd party requesting an updated location via this
> mechanism is more efficient than the end-device requesting an updated
> location on it's own behalf.

There are two different concepts in play here: -conveyance- by-reference and -provisioning- by-reference. You can have one without the other, certainly. This draft is focused on -provisioning- by-reference (that is, providing a URI to an endpoint that it can communicate to application-layer services to say, "this is where you can find my current location information"). It does however provide some arguments related to conveyance by-value. I can see that the two need to be more strongly distinguished in the text.

> 5) "By contrast, by-value provisioning in these sorts of environments would
> result in continual and probably unnecessary updates to all endpoints for
> the benefits of the few that will ultimately require location-based
> services."
> 
> Please provide pointers to 'by-value provisioning' mechanisms that provide
> continual and probably unnecessary updates.

The cited sentence contains the word "would", which expresses here a counterfactual conditional. No one to my knowledge has proposed a by-value location information endpoint provisioning system that accommodates mobile targets. On the surface, it doesn't seem like a very good idea. Hence the need for some alternative provisioning system for these sorts of cases.

> 6) "In addition to access technologies having an impact on location, so too
> network topologies have an impact on location determination and acquisition.
> It is not uncommon for broadband services to be provided to end-consumers
> through infrastructure owned and operated by several different
> organizations.  Such networks generally do not comprise of single DHCP
> servers, but rather use AAA and RADIUS devices, often in proxy
> configurations, to obtain and distribute  configuration information.
> Modifying such systems to include native support for location acquisition
> proliferates a problem that is already starting to take hold in a number of
> layer 2 based protocols. An alternative approach is to provide a location
> reference mechanism that can be common across all access configuration
> protocols allowing simplification and solution consolidation."
> 
> Please explain how this new conveyance mechanism will make life simpler at
> the lower layers?  Are not access device port wire maps still utilized?
> What protocols are going to deliver this data to this new magic box?

Port wire maps? If you have those, why not use RFC3825?

I don't think anyone proposes any kind of "magic box" here. I believe it is the case that an entity in the network can know your location information, and can provide you with a URI where that location information can be retrieved. I believe this has applicability to certain network architectures which are outside the scope of RFC3825. I'm not sure why this idea seems so magical, there are a number of use cases to which this would have applicability. For example:

- I manually provision my VoIP service provider's web site with my location information. When my SIP device associates with my VoIP provider, it somehow communicates to my device "this is the URI where your location information can be found". That way, when I buy a new SIP phone (one which doesn't have much by way of a provisioning interface, we'll say), when I register with my VoIP service provider, it just learns how to point to my location information. Access network, in this case, has no bearing on anything. Works well for static landline SIP phones in the absence of any access network location information.

- My 3G wireless provider knows my location information by triangulation. Their collective systems that triangulate my location information serve as input to an LG that they operate. When I associate my 3G SIP phone with my wireless provider (i.e., through registration), it sends me a SIP URI of an LS (we'll say a follow-blown presence server) where my location information can be found. I can dereference this URI myself if I want to get my own location information, or send it to network services that can dereference it.

Could this be applicable to cases where a wireline access network knows your location information? Possibly, sure. I can imagine a DHCP server sending a URI to my device instead of LCI, say. Would this be optimal? Probably not in most cases. The access network would need to run some additional servers where the resources indicated by those URIs are made available, which is undoubtedly more complicated than LCI. In any event, this proposal is not presenting itself as being superior to LCI in LCI's domain of applicability. It is focusing more on the sorts of use cases described above.

> 7) "Location not explicitly included in provisioning messages, but available
> to authorized nodes (which may or may not include the provisioned endpoint)."
> 
> Please expand on how these nodes are authorized?  

Through the policies published by the rule-maker(s), of course, the same way location information is always authorized.

> Please explain failure modes when authorization does not work?  

If you are not authorized to receive location information, you don't get it. In the RFC3825 model, if I learn my location information, and act as an LG to publish it to an LS, and an unauthorized LR tries to fetch it from the LS, they don't get it. Your problem here is...?

> Please provide guesstimate of added SIP call setup latency.

That is a question about conveyance by-reference, not provisioning by-reference. The answer to that depends on what the deployment architecture looks like, what kinds of URIs are used in by-reference conveyance, and where they are deferenced. So, the answer depends. I'm sure we can envision networks in which it would have an appreciable impact, and others in which it would not.

The ironic thing about this is course is that if you provision by-reference, then an authorized client could just dereference its own URI, learn its location information, and convey it by-value. Honestly, by-reference provisioning is completely orthogonal to by-reference conveyance.

> 8) "Smaller messages traverse much of the network, larger location
> components only retrieved as required.  Less load on access network elements
> as location is only generated and supplied as required."
> 
> Please explain the less load statement.  If the access network is involved
> in location determination, then why is there less load when using a
> different conveyance mechanism?

The cited text speaks to a hypothetical access network that provisioned mobile endpoints by-value, sending constant updates or whatever. That would create more load than a by-reference provisioning system.

> 9) "End-devices do not need to maintain a trust relationship with the
> location recipient in order for the location recipient to obtain the
> end-device's location."
> 
> Explain how this meets RFC-3693 and the GeoPriv charter?

Explain why you think it doesn't. You really think that 'end devices' (i.e. targets) are positioned in the GEOPRIV charter or requirements as devices that need to maintain a trust relationship with the location recipient? Do you think that endpoints, or the controllers of endpoints, are necessarily rule-makers?

> 10) "Location consumers obtain location directly from the generator for a
> given end-point increasing location dependability and reducing unnecessary
> transitive trust (where recipients would have to trust the consumer
> "through" a user-controlled endpoint)."
> 
> Explain how/why the consumer should trust the generator?  What if the
> end-point and Location URI are the same entity?

Again, "directly from the generator" here is a misnomer; in the GEOPRIV architecture a generator is not an entity that shares location information. It should say, "directly from the location server of the generating domain", or something. I think the text tacitly assumes that the generator and location server are under a common administration, and thus uses generator to refer to the whole shebang.

Your first point is an important question, and one of the ones that I hoped the draft would bring to the fore. In the first place, in the GEOPRIV architecture, an LR needs to trust an LS, and an LS is provisioned by an LG (and thus needs to trust an LG). In other words, an LR necessarily transitively trusts an LG. By definition, accepting a piece of location information means trusting its generator.

The reason why by-reference -conveyance- makes this trust more direct than by-value conveyance is that the PIDF-LO object itself is not tunneled through a user-controlled device (the endpoint), only a reference is so tunneled. The reference itself does not share the security properties of the object, it's just a pointer. A reference doesn't need to have confidentiality or integrity properties, only the data to which it points (and the system that determines who gets access to that data) needs to have those properties. As a URI is derefenced, a direct connection can be established between the consumer and provider of location information. That direct connection avoids any uncertainty interjected by a middleman (namely a client) and simplifies confidentiality and access control problems.

Strictly speaking, an endpoint cannot be the same entity as a Location URI - the first is a physical object and the second is just a byte string. I'm not sure exactly what you meant here. Maybe you mean that the endpoint runs the server (SIP or web server, maybe) to which the URI points? That is possible, though perhaps not useful in many architectures.

> 11) "Location is determined at request time resulting in more current
> locations being returned, especially in dynamic environments where location
> might change over time."
> 
> Is it assumed that requesting a new location determination is restricted to
> this Location URI mechanism?  I don't see the relevance to this statement
> when discussing/contrasting location conveyance mechanisms.

Requesting a new location determination requires a request/response protocol and the ability for the party that wants to know location information to identify the party to whom a request needs to be sent. Identifying a protocol and a network resource that the protocol can target is typically the business of URIs. There are mechanisms other than a URI that might conceivably meet these criteria. However, when we start looking at conveyance cases, it seems unlikely that something other than a URI would be practically servicable.

> 12) "Can be easily integrated into existing presence architectures to make
> use of existing privacy, authorization and authentication techniques."
> 
> Please expand on this.  I missed how the privacy rules are distributed in
> this document.

This document has no implications for the existing privacy mechanisms defined in GEOPRIV; they work as they have always worked. XCAP, location servers, common profile, etc.

> 13) "Compensates well for network-layer tunnels etc as location-reference
> can be provided at the local level."
> 
> How does passing a Location URI change the difficulty for location when
> tunnels are used?

Eh, I'm a little skeptical about that one myself. I guess ultimately, though, I think the problem of understanding what network interfaces an endpoint has available, and how those interrelate, is a problem likely to be solvable only at the application layer. No DHCP or RADIUS protocol exchange is going to tell you about the total set of interfaces associated with your device. That's something an application can discover, though, by talking to the operating system.

Jon Peterson
NeuStar, Inc.
 
> -Marc-
> 
> Marc Linsner
> Consulting Engineer - Corporate Development
> Cisco Systems, Inc.
> +1-239-272-2105
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 22 Jul 2005 12:00:31 -0400

btw, deleting portions of your response should not be construed as
agreement, just requires more thought on my part...:^)

snip........
> 
> "Dependability" in this context means something closer to 
> "assurance" or "trust". Basically, this text looks forward to 
> the arguments for location -conveyance- by-reference. The 
> point this is trying to make is that any uncertainty or 
> unreliability that might be introduced in the system by using 
> the endpoint as a middleman between the generator and the 
> recipient can be reduced if location is conveyed by-reference.

But this is simply a marketing spin targeted at the consumer of location.
I'm pushing back on this as there is an audience for these drafts that
actually believe the words.  Is not the endpoint still the middleman?  It's
not clear (at least to me) why a miscreant would not/could not alter the
reference, thus redirecting the LR to a perceived trustable service.  In
this case, is not data believed to be dependable more dangerous than known
suspect data?

snip......
 
> > Plus, please expand on the idea that a location generator 
> may withhold 
> > information pertaining to an end-point from the end-point?  
> Business 
> > reason (holding location information hostage for money)?
> 
> I am being held hostage in this fashion by all of my wireless 
> providers at this moment, as are many of the people reading 
> this mail, I suspect.
> 

Not a convincing argument to continue/further this model, but I suppose it
depends on your viewpoint.

snip.....

> 
> > 5) "By contrast, by-value provisioning in these sorts of 
> environments 
> > would result in continual and probably unnecessary updates to all 
> > endpoints for the benefits of the few that will ultimately require 
> > location-based services."
> > 
> > Please provide pointers to 'by-value provisioning' mechanisms that 
> > provide continual and probably unnecessary updates.
> 
> The cited sentence contains the word "would", which expresses 
> here a counterfactual conditional. No one to my knowledge has 
> proposed a by-value location information endpoint 
> provisioning system that accommodates mobile targets. On the 
> surface, it doesn't seem like a very good idea. Hence the 
> need for some alternative provisioning system for these sorts 
> of cases.

Are you suggesting that by-reference just might fill that 'alternative
provisioning system' need?  I guess I'm missing something. I'm thinking that
by-value equals passing of actual location data and by-reference equals
passing a place where location data can be obtained.  The original sentiment
here (more spin?) is that in instances where location data is changing
(mobile devices) the by-reference mechanism is more efficient.  The
statement is "by-value provisioning in these sorts of environments would
result in continual and probably unnecessary updates".  I see no connection
between the frequency of determining location of a mobile device and the
distribution of the resulting data.  My original query was to discover a
mechanism, or potential mechanism, that causes 'continual and probably
unnecessary updates'.

snip......

> > Please explain how this new conveyance mechanism will make life 
> > simpler at the lower layers?  Are not access device port 
> wire maps still utilized?
> I don't think anyone proposes any kind of "magic box" here. I 
> believe it is the case that an entity in the network can know 
> your location information, and can provide you with a URI 
> where that location information can be retrieved. I believe 
> this has applicability to certain network architectures which 
> are outside the scope of RFC3825. I'm not sure why this idea 
> seems so magical, there are a number of use cases to which 
> this would have applicability. For example:
> 
> - I manually provision my VoIP service provider's web site 
> with my location information. When my SIP device associates 
> with my VoIP provider, it somehow communicates to my device 
> "this is the URI where your location information can be 
> found". That way, when I buy a new SIP phone (one which 
> doesn't have much by way of a provisioning interface, we'll 
> say), when I register with my VoIP service provider, it just 
> learns how to point to my location information. Access 
> network, in this case, has no bearing on anything. Works well 
> for static landline SIP phones in the absence of any access 
> network location information.
> 
> - My 3G wireless provider knows my location information by 
> triangulation. Their collective systems that triangulate my 
> location information serve as input to an LG that they 
> operate. When I associate my 3G SIP phone with my wireless 
> provider (i.e., through registration), it sends me a SIP URI 
> of an LS (we'll say a follow-blown presence server) where my 
> location information can be found. I can dereference this URI 
> myself if I want to get my own location information, or send 
> it to network services that can dereference it.
> 
> Could this be applicable to cases where a wireline access 
> network knows your location information? Possibly, sure. I 
> can imagine a DHCP server sending a URI to my device instead 
> of LCI, say. Would this be optimal? Probably not in most 
> cases. The access network would need to run some additional 
> servers where the resources indicated by those URIs are made 
> available, which is undoubtedly more complicated than LCI. In 
> any event, this proposal is not presenting itself as being 
> superior to LCI in LCI's domain of applicability. It is 
> focusing more on the sorts of use cases described above.

OK, so let's spin this as an alternative mechanism and cite the use cases.
I've always agreed that there needs to be alternatives to 3825 and like
mechanisms, as stated within that RFC itself.

snip......

> If you are not authorized to receive location information, 
> you don't get it. In the RFC3825 model, if I learn my 
> location information, and act as an LG to publish it to an 
> LS, and an unauthorized LR tries to fetch it from the LS, 
> they don't get it. Your problem here is...?

My thoughts extend to ecrit.  In the 'by-value' case where a UA includes an
encrypted pidf-lo on an emergency call invite, the proposed mechanism states
that if there is no response from the routing element (proxy), assume an
encryption problem and resubmit the invite without encrypting pidf-lo.  In
the by-reference model, there could be a situation where there is no chance
of recovering from a routing element that fails authorization at the LS.
Hence emergency calls fail.

> That is a question about conveyance by-reference, not 
> provisioning by-reference. The answer to that depends on what 
> the deployment architecture looks like, what kinds of URIs 
> are used in by-reference conveyance, and where they are 
> deferenced. So, the answer depends. I'm sure we can envision 
> networks in which it would have an appreciable impact, and 
> others in which it would not.
> 
> The ironic thing about this is course is that if you 
> provision by-reference, then an authorized client could just 
> dereference its own URI, learn its location information, and 
> convey it by-value. Honestly, by-reference provisioning is 
> completely orthogonal to by-reference conveyance.

'then an authorized client could just dereference its own URI'
This is counter to the earlier statement, 'some generators of location
information might not want to disclose this information directly to
endpoints for various business-model reasons'  So the person making an
emergency call that doesn't have the quarter in their pocket to pay for the
location data can't make an emergency call?

> > components only retrieved as required.  Less load on access network 
> > elements as location is only generated and supplied as required."
> > 
> > Please explain the less load statement.  If the access network is 
> > involved in location determination, then why is there less 
> load when 
> > using a different conveyance mechanism?
> 
> The cited text speaks to a hypothetical access network that 
> provisioned mobile endpoints by-value, sending constant 
> updates or whatever. That would create more load than a 
> by-reference provisioning system.

As noted above, we can't seem to identify a system that sends 'constant
updates or whatever'.  So I suggest to remove references to hypothetical
cases that outwardly appear as spin.

> Explain why you think it doesn't. You really think that 'end 
> devices' (i.e. targets) are positioned in the GEOPRIV charter 
> or requirements as devices that need to maintain a trust 
> relationship with the location recipient? Do you think that 
> endpoints, or the controllers of endpoints, are necessarily 
> rule-makers?
> 
> > 10) "Location consumers obtain location directly from the generator 
> > for a given end-point increasing location dependability and 
> reducing 
> > unnecessary transitive trust (where recipients would have 
> to trust the 
> > consumer "through" a user-controlled endpoint)."
> > 
> Again, "directly from the generator" here is a misnomer; in 
> the GEOPRIV architecture a generator is not an entity that 
> shares location information. It should say, "directly from 
> the location server of the generating domain", or something. 
> I think the text tacitly assumes that the generator and 
> location server are under a common administration, and thus 
> uses generator to refer to the whole shebang.
> 
> Your first point is an important question, and one of the 
> ones that I hoped the draft would bring to the fore. In the 
> first place, in the GEOPRIV architecture, an LR needs to 
> trust an LS, and an LS is provisioned by an LG (and thus 
> needs to trust an LG). In other words, an LR necessarily 
> transitively trusts an LG. By definition, accepting a piece 
> of location information means trusting its generator.
> 
> The reason why by-reference -conveyance- makes this trust 
> more direct than by-value conveyance is that the PIDF-LO 
> object itself is not tunneled through a user-controlled 
> device (the endpoint), only a reference is so tunneled. The 
> reference itself does not share the security properties of 
> the object, it's just a pointer. A reference doesn't need to 
> have confidentiality or integrity properties, only the data 
> to which it points (and the system that determines who gets 
> access to that data) needs to have those properties. As a URI 
> is derefenced, a direct connection can be established between 
> the consumer and provider of location information. That 
> direct connection avoids any uncertainty interjected by a 
> middleman (namely a client) and simplifies confidentiality 
> and access control problems.
> 
> Strictly speaking, an endpoint cannot be the same entity as a 
> Location URI - the first is a physical object and the second 
> is just a byte string. I'm not sure exactly what you meant 
> here. Maybe you mean that the endpoint runs the server (SIP 
> or web server, maybe) to which the URI points? That is 
> possible, though perhaps not useful in many architectures.

Let me give an example of a useful architecture:  The trust construed via
the by-reference mechanism is more subject (IMO) to falsification than the
LR simply being suspect of all data.  So, the usefulness of directing a LR
to an appearance of a trustable LS is very advantageous in the hacker world.

> > locations being returned, especially in dynamic environments where 
> > location might change over time."
> > 
> > Is it assumed that requesting a new location determination is 
> > restricted to this Location URI mechanism?  I don't see the 
> relevance 
> > to this statement when discussing/contrasting location 
> conveyance mechanisms.
> 
> Requesting a new location determination requires a 
> request/response protocol and the ability for the party that 
> wants to know location information to identify the party to 
> whom a request needs to be sent. Identifying a protocol and a 
> network resource that the protocol can target is typically 
> the business of URIs. There are mechanisms other than a URI 
> that might conceivably meet these criteria. However, when we 
> start looking at conveyance cases, it seems unlikely that 
> something other than a URI would be practically servicable.
> 
> > 12) "Can be easily integrated into existing presence 
> architectures to 
> > make use of existing privacy, authorization and 
> authentication techniques."
> > 
> > Please expand on this.  I missed how the privacy rules are 
> distributed 
> > in this document.
> 
> This document has no implications for the existing privacy 
> mechanisms defined in GEOPRIV; they work as they have always 
> worked. XCAP, location servers, common profile, etc.
> 
> > 13) "Compensates well for network-layer tunnels etc as 
> > location-reference can be provided at the local level."
> > 
> > How does passing a Location URI change the difficulty for location 
> > when tunnels are used?
> 
> Eh, I'm a little skeptical about that one myself. I guess 
> ultimately, though, I think the problem of understanding what 
> network interfaces an endpoint has available, and how those 
> interrelate, is a problem likely to be solvable only at the 
> application layer. No DHCP or RADIUS protocol exchange is 
> going to tell you about the total set of interfaces 
> associated with your device. That's something an application 
> can discover, though, by talking to the operating system.

Again, my problem is more with the spin.

-Marc Linsner-