RE: [Geopriv] coming to terms on location by reference

Paranoia rules... by "owner" I intended the "user" of the "device" which
constitutes the "target" of the location determination. That's all I
meant.

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 14 September 2006 11:42 AM
> To: Dawson, Martin; 'Marc Linsner'; 'Andrew Newton'; geopriv@ietf.org
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> This isn't NENA. There is a meeting next week where you can ask the
i2.5
> folks if they believe mobility is well specified in the current
document.
[[Martin Dawson] ] :) classic.

>
> > The list I previously sent:
> >
> > Practical benefits of location reference:
> > * The literal location does not need to be transmitted in band.
Where
> > the eventual recipient and de-referencer is the only party the
"owner"
> > of location cares to provide disclosure to, then the reference
mechanism
> > achieves this. Particularly useful where the owner is not in a peer
> > signaling relationship with the de-referencer. E.g. a VoIP emergency
> > caller and a VPC.
> Your example is pretty poor because the LIS does not know who must
route
> the
> call based on location. It must allow anyone with the reference to
get
> location to route. The mechanism explicitly does not restrict any
proxy
> on
> the path from routing based on location. It encourages this early,
but
> the
> LIS has no idea what that means.
[[Martin Dawson] ] In i2 the call server asks the VPC for routing
information. If it provides a reference in that request then the VPC
de-references and requests the location from the LIS. The call server is
not authorized to dereference, the VPC is. Beats the heck out of me why
that's a poor example.

>From a previous post, you stated you didn't think the LIS would apply
authentication/authorization to permit de-referencing. I certainly don't
agree with that but perhaps it explains your comment above.

>
> I'm intrigued with the word "owner". You didn't use "target", "user"
or
> "endpoint". Did you mean to imply that, for example, the access
network
> could claim it is the owner, and therefore is in control of the
ruleset?
> I
> think we would disagree with that.
>
> If the "owner" is indeed the target (or the user associated with the
> target), and it does know the "eventual recipient", then it could
> straightforwardly send location to that recipient. For example, it
could
> S/MIME encrypt it with the key of that recipient. We're assuming here
> that
> the attached ruleset is not sufficient security, which is reasonable.
You
> said "owner is not in a peer signaling relationship", but if you can
pass
> the reference, you can pass the value.
[[Martin Dawson] ] Bang bang bang - nice brick wall... in i2 there is no
peer signaling relationship between the VPC and the device. The VPC
needs an alternative route to obtain updated locations. The device can't
provide an arbitrary future location by value in the call initiation.

>
> I generally think presence is the kind of thing you probably want to
use
> here, especially if the device is mobile.
[[Martin Dawson] ] Well maybe. But we cannot require presence for
emergency services support. Hey, I thought the vision of i3 was to
eliminate all forms of "operator"... ;) A presence operator is
conceptually an evolution of an HLR operator running a cellular network.
Now VoIP emergency callers are chained to a presence operator?

>
> >
> > * The location reference form is immutable and generic (i.e. a URI -
and
> > my view that a generic URI is perfectly adequate has also been
> > expressed). So, no matter what eventual modifications, extensions,
or
> > additions are made to the manner in which the PIDF-LO is formed, the
> > conveyance path need not be concerned about backward
incompatibility.
> > Adaption is limited to the actual end-user of the location
information.
> This is also a characteristic of XML, which is how PIDF is formed. So
the
> LbyR has the same characteristic.
[[Martin Dawson] ] Ideally, but backward incompatibilities still occur
with XML specifications. Been working in OMA on the MLP spec by any
chance? Insulating the conveyance from such artifacts is a benefit. I
listed it in the benefits.

>
> >
> > * Where the location owner is not in a peer signaling relationship
with
> > the location user (e.g. a VoIP emergency caller and a VPC), the
location
> > reference can be permitted to be valid for a period of time
allowing,
> > for example, the retrieval of location updates during the period of
that
> > session.
> Well, the thing is here that you are talking about updates. If you
were
> just using LbyV, you would get your update from the endpoint, and it
would
> control how long you were allowed to see the data. If the endpoint is
> willing to give location for emergency calls, than it is willing to
give
> it
> to the VPC. It would allow a "peer signaling relationship" for this
> purpose.
>
> Also a presence mechanism, of course.
[[Martin Dawson] ] Bang, bang, bang... If I don't have a network
topology that includes a peer signaling relationship with the device
and/or works independently of presence functions (e.g. the i2
architecture), I don't have that luxury.

>
> >
> > * As a counter-response - no the location reference is not less
secure.
> > Losing privacy of location information means losing the information
at
> > the device or in transit. Loss of a literal location object means
the
> > location is lost in one step. Loss of a reference still requires the
> > unauthorized party to successfully breach the authentication and
> > authorization barrier at the referenced server. Location by
reference
> > provides superior privacy.
> Here we just disagree. I think many of us don't believe we can create
a
> sufficiently robust authentication system. We may need a rough
consensus
> determination on this point. I wish it were true, I don't think it
is.
[[Martin Dawson] ] Then, presumably, you don't use on-line banking
either. A very hackneyed conversation. If you can come up with another
and more reliable way to convey identity in the Internet where there is
a relationship decoupling between the client and the server other than
certificates, then you can make yourself a fortune. As far as I know,
the only way that this can be done is by certificates and public key
encryption using evolving ciphers. It is a consequence of the Internet
services model - and goes way beyond the narrow application domain of
emergency services. It's why architectures such as FIPS have been
developed - because cert management is the cost of reaping the benefit
of this decoupling. If it can't be made to work, then many service
concepts are doomed. I believe it can work. While you recently described
yourself as a "cert optimist" I mostly hear you advocating despair. I
absolutely agree - we just disagree :).

>
> >
> > * The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al
> > recently does not address the temporal component. Brian should state
the
> > signature also needs to provide an expiry-time component. Else the
> > signed LO can be replayed at any time in the future from anywhere by
the
> > original recipient. Expiry time semantics are somewhat awkward.
Since
> > de-referencing is an instantaneous process, the location server can
> > apply temporal rules directly without the need to encode them in the
> > location object itself.
> I agree. All forms of LbyV should have a timestamp, they should have
a
> TTL
> and those should be in a signature if there is one
[[Martin Dawson] ] Quite right - that's the solution we have proposed
for inclusion in the location value DSIG. However, how long should it
be? Will it be long enough for the intended purpose? Alternatively,
should it be a UTC timestamp and should the recipient apply the policy
on how long is long enough or does the client/LIS somehow mandate that?
When a location is obtained by instantaneous de-reference, the location
user has no doubt that the location is instantaneously applicable to the
target in question. This is easier and less ambiguous. It's a benefit of
location reference; so I list it.

>
> >
> > * Since a LIS can provide many forms of location (Civic, Postal
Civic,
> > Jurisdictional/Emergency civic, Geodetic, and arbitrary other forms
that
> > may be added later) a de-referencing application may request the
form
> > which is of specific interest to it. This obviates the need for the
> > client device to divine the form in advance of conveyance or to
request
> > and send every possible form of location from the LIS before sending
> > by-value.
> This is a protocol issue: if the protocol supports the client
requesting
> the
> type of location, then the server can respond. While I agree that the
> endpoint is unlikely to contain a geocoder, it can ask for both forms
from
> the LIS and then supply whatever form the client wishes. If the
protocol
> doesn't have this feature, then of course you can't get that result.
[[Martin Dawson] ] But, of course, if there are many useful forms of
location a LIS can provide (or do you claim we have now identified all
present and possible useful forms of location?) then the device has to
either ask for them all or work out what the application really needs.
Since a dedicated session between the application and LIS allows the
application to request the form it really needs, this complexity is
eliminated. That's a benefit. The device implementation of the protocol
may not know about the new form but the application would (by
definition, since that's what it's interested in). The device
implementation doesn't need to if it just asks for a reference. That's a
protocol evolution benefit, so I list it.

>
> >
> > In terms of using location-by-reference to avoid location-by-value -
I
> > believe there are deployment models that will want to do that for
any
> > number of reasons (I articulated the scenario of a scientist
tracking a
> > set of weather balloons providing a low power pulse tracked by
uplink
> > timing measurements). This is a valid application for location
reference
> > and it should be supported. I am not interested in - and it is not
> > appropriate for a protocol specification to be evaluated on -
> > requirements defined based on business imperatives. Business models
> > succeed or fail independently of the protocol specification as long
as
> > the specification supports alternative options.
> Agree that a business model doesn't make a good requirement for a
> protocol,
> but it sure wouldn't be the first time this has happened. The current
L7
> discussion is highly influenced by business models of one form or
another
> and not on engineering issues. Before you yell, I think there are
> sufficient actual requirements to do an L7 protocol.
[[Martin Dawson] ] Of course, discussions are influenced by business
models. Most forums start with some form of self-interest, including a
desire to provide a social service. With sufficient broad
representation, the protocol should have sufficient options to satisfy
the individual needs, without bias toward or against one or the other,
as efficiently as possible, and without internal contradiction.

>
> I don't believe your example is particularly valid. I think you can do
> LbyV
> as easily as LbyR and have fewer problems. YMMV. I think I want to
see a
> requirement that is clear cut. It's one thing to say that, for
example,
> not
> every network can be configured to support DHCP and/or LLDP-MED in
such a
> way that it is possible to support location solely by that mechanism.
I
> can
> say that such networks might be few and far between, but they exist,
and
> will exist. That is a requirement for at least another protocol, if
not
> an
> L7 protocol.
>
> What is the actual requirement that drives LbyR?
[[Martin Dawson] ] Bang, bang, bang...
>
> ps - I really don't believe we are going to abandon LbyR, because we
have
> presence, and presence is LbyR. Even assuming that presence is the
ONLY
> LbyR we do, it still does what you want it to do. Still, it would
really
> be
> nice to have a crisp requirement that we could all agree on.
[[Martin Dawson] ] I don't want to have to have a presence server
subscription to be able to use Internet based location services. For
example, if I want to use a speed-camera alert web application that uses
location updates directly via the provided reference to my WiMAX
provider's LIS, I don't want to *have* to be using a presence service. I
might add that the assumption of such a requirement would seem to be at
odds with much of the opinion previously expressed by some.

>
> >
> > In terms of the LIS applying policy beyond that provided by the
device.
> > Yes - jurisdictions that provide location for emergency services
> > regardless of the client policy are an example of that function.
> Yeah, sort of. What you imply is that the endpoint can withhold
anything
> it
> doesn't want to give the PSAP, regardless of what the law says. True,
> although I don't think we engineer protocols around that. The problem
> with
> your argument is that the endpoint can refuse to send the reference,
and
> unless the VSP can supply it (which depends on the VSP relationship
with
> the
> access network), the LIS can't help.
[[Martin Dawson] ] I wasn't attempting to imply the point you inferred.
You'd asked whether I thought the device provided policy would be the
only policy applied. I don't think that is the case - neither do you
from comments made elsewhere. Other than that, what's your point? If
location is not provided by either value or reference by the device than
emergency call processing by a pure VoIP provider can't proceed? Uh...
yes.

>

------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 13 Sep 2006 21:32:00 -0500