Subject: [Geopriv] Naive question: LCP == LbyR?

From: Richard Barnes <[email-masked]>
Date: Mon, 26 Feb 2007 13:03:03 -0500

I've got a simple question, that's basically captured by the subject 
line: What's the difference between a Location Configuration Protocol 
and an L-by-R Dereference Protocol?  Compare two use cases:

LCP:
Step 1. Discover LIS
Step 2. Send query to LIS
Step 3. Receive LO / URL

L-by-R:
Step 1. Receive location URL
Step 2. Send query to dereference server
Step 3. Receive LO / URL

I realize that with an LCP, there's a additional need to identify the 
target, but it seems just as easy to embed this into a URI or 
dereference request as  to use another protocol mechanism.  And it seems 
like using a single protocol for both would save us all some time and 
effort.

Cheers,
--Richard

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Feb 2007 12:13:51 -0600

Simplistically, an LCP is the whole protocol transaction of 
discovery, query and receive Location Object or referenceable URI 
(where location info is stored for a particular entity).

LbyR is just the URI (pointing at the information record indicating 
where a particular entity is when last it was 'sighted'), which can 
be delivered any number of ways to a server or other endpoint, or 
sent any number of ways (as part of a protocol transaction)

At 12:03 PM 2/26/2007, Richard Barnes wrote:
>line: What's the difference between a Location Configuration 
>Protocol and an L-by-R Dereference Protocol?  Compare two use cases:
>
>LCP:
>Step 1. Discover LIS
>I realize that with an LCP, there's a additional need to identify 
>the target, but it seems just as easy to embed this into a URI or 
>dereference request as  to use another protocol mechanism.  And it 
>seems like using a single protocol for both would save us all some 
>time and effort.
>
>Cheers,
>--Richard
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 26 Feb 2007 14:05:32 -0500

The fundamental difference is that the LCP gives an endpoint its own
location (or a reference to it), and LbyR dereferences for (at least
theoretically) anyone.

LCP needs an identifier for an endpoint; typically an IP or MAC address.
LbyR needs a real URI which ideally has no user identifiable information in
it (except in the case of presence, where you may well have an AoR)

LCPs need discovery, LbyR provides the server address in the URI

You never get a URL from an LbyR dereference; you always get an LO.

The security properties are different, primarily due to the first (self
only, vs world) difference above.

Other than that, they are the same.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, February 26, 2007 1:03 PM
> To: 'GEOPRIV'
> Subject: [Geopriv] Naive question: LCP == LbyR?
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 26 Feb 2007 19:13:46 -0500

Brian,

Thanks for your reply.  As an aside, I should make clear that I'm 
referring only to an L7 LCP, and not to lower-layer LCPs such as DHCP or 

> LCPs need discovery, LbyR provides the server address in the URI

To quote draft-thomson-geopriv-lis-discovery: "The product of a 
discovery process ... is the address of the [LIS] service."  This 
address (a URI, in fact, in that draft) conveys the address of the 
server, and a protocol to use.  Implicitly, this also specifies the 
identifier(s) that should be used to retrieve location and how they 
should be communicated.  All in all, this tells the target what server 
to contact, and how to request what it wants -- the same thing that a 
location URI provides.  So LIS discovery in an LCP seems entirely 
analogous to the delivery of a location reference to a location recipient.

Maybe the right way to say it is that an LCP is the discovery of an LIS 
URI, followed by a location (LbyR) dereference.

> it (except in the case of presence, where you may well have an AoR)

A location URI must identify the entity that it's locating (even if 
that's via a table of random#->AoR mappings in the server), since the 
dereference server has use it to figure out which location to return.

Now, for privacy reasons, the dereferencing entity in an LCP might not 
want to encode its identifier(s) in a URI, but there are other, more 
confidential ways to do this an the dereference protocol.  For example, 
the identifier could be passed as a header within an HTTPS channel.

> theoretically) anyone ... The security properties are different, 
> primarily due to the first (self only, vs world) difference above.

While those are different use cases, I don't think they make very 
different requirements on the protocol.  If you want to assure that the 
LCP can't be spoofed by an attacker to get user locations from an LIS, 
you'll have to make sure that an entity making a request from an LIS is 
actually the holder of that identifier.  In the right environment, with 
the right identifiers, you could do this authentication at the physical 
or MAC layers, but above that, you might as well use the authentication 
mechanism(s) to be provided by an LbyR protocol.

> You never get a URL from an LbyR dereference; you always get an LO.

We could debate the semantics of "LbyR" but one could view Henning's 
proposal for getting randomized URIs as an LbyR system that results in 
location by value.  This broader meaning seems more flexible to me.

[NB: I am aware that this requires modification to 
draft-marshall-geopriv-lbyr-requirements]

Cheers,
--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 19:19:38 -0600

Richard,

I think that you and Brian aren't necessarily disagreeing, because I think that I agree with both of you.

I see that there are two discrete parts to the problem.  The first is entirely separable from the second.

> Step 1. Get URI

For an acquisition protocol, this URI might be common to an entire network.  The example that I've used is "https://lis.example.com/".  This could be widely known.

In contrast, the dereference protocol requires a URI that is unique to a target.  This could be a secret value, shared only within a certain group.  This is acquired by conveyance.

To date, the initial discovery of a location reference has been the domain of the query step...

> Step 2. Query

In this step, you are right that there is some commonality -- if all you are retrieving is a location object.  The semantics are largely the same.  Sharing semantics between these protocols makes sense.

One important distinction is that the reference in the dereference protocol can be used to identify the Target.  In an acquisition protocol (or LCP), other information must be available, such as the source IP of the request, or the "identifiers" described in l7-lcp-ps.

> Step 1.5. Acquire Reference

The acquisition protocol (or LCP) also has the option of retrieving a location reference.  This is done because the "dereferencee" (i.e. the target of the reference) has to be able to generate location information, so it is likely to be a LIS.  We can consider this an intermediate step (i.e. step 1.5) if we like, but since the entity providing this reference is almost always the LIS, there's a benefit in being able to skip this step.

Acquiring a reference is a feature the dereference protocol does not need to share.  After all, if you already have a reference, what need is there to get another?  So from that perspective, it makes sense to separate that function.

The main reason that we talk about these separately is the use case difference (self or world) and the associated complications; however, I can see your point.  It would not be constructive to have two entirely separate protocols for these cases.  A common set of semantics can be shared between the two, once the security considerations are handled.  Separate discussions of security and privacy considerations are still necessary to cover the distinct use cases.

LIS discovery and conveyance (finding the URI) are distinct functions, but I can agree on some level of commonality in the location "retrieval" protocols.  We may have to have some more discussion on how and where the reference acquisition occurs.

Cheers,
Martin

> Sent: Tuesday, 27 February 2007 11:14 AM
> To: Brian Rosen; 'GEOPRIV'
> Subject: Re: [Geopriv] Naive question: LCP == LbyR?
> 
> Brian,
> 
> seems

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Feb 2007 08:16:39 -0500

I'm sure we can develop one protocol to do both jobs.

Let's use SNMP.  I'm sure we can get it to work.

If you squint hard enough, any protocol can do whatever task you want it to.

That's not usually the way we do things around here.  Sometimes, it happens.
For example, sip, which we usually think of as a multimedia session
establishment protocol, happens to work as an LbyR dereference protocol,
because you can start with an sip URI and get a PIDF from it using presence.
We could bend sip to use it for an LCP.  It's been proposed (registration
could return a location using -conveyance).  I don't want to go there.

I don't think L7 LCP and LbyR dereference is the same thing.  We may end up
with two things that look alike.  I don't think so, but "look alike" is in
the eye of the beholder.  We'll see.

Brian

> Sent: Monday, February 26, 2007 7:14 PM