RE: RE: [Geopriv] Consensus on changes to location-conveyance

> > I don't really understand why you think location by reference is so much
> of
> > a concern.
> 
> It is interesting that you say that. In the Geopriv L7 design team you
> are the only person that wants to see an applicability statement being
> written.
We haven't gotten to that yet, but it's a problem of proxy assertion, not
location-by-reference.  Basically, coming up with an identifier to determine
what location to assert (by value or by reference) is much worse than the L7
case, because the SIP signaling plane definitely is subject to being carried
over VPNs and other IP address obscuring things.  You can't possibly use the
IP address as the identifier.  You have to use something else.  What else?
I have no idea.  I can imagine some kinds of wireless systems being able to
know that the device is on their own network, and have some id that works on
that network.

In case I have not been clear enough, I personally DO NOT LIKE proxy
assertion of location.  I do not really like location by reference, although
a SIP presence URI is location-by-reference no matter how you slice and dice
it.

However, I consider both to be requirements in location-conveyance, and
think limiting proxy insertion to be by reference only to be the least
objectionable answer.

> 
> Having a SIP proxy adding something (either location-by-value or
> location-by-reference) is not different to the stuff we discuss in the
> design team. There, you see a lot of privacy, security, etc. problems.
> Here you don't. How come?
I see plenty of problems, but in a protocol sense I don't think anything is
different other than this identifier problem.

> 
> If you go through my mail with the large number of scenarios then you
> find a number of open issues that need to be answered. Alternatively,
> you can also go through draft-tschofenig-geopriv-l7-lcp-ps-00.txt
> 
>   If you look at the discussion in context, PIDF-LO defines
> > location as part of presence.  All of these concerns are relevant there,
> and
> > I think they have been adequately covered there.  We even have some work
> on
> > anonymization of the identity (and thus of the URI) in presence.
> Generally,
> > a presence uri:
> >
> > Is not valid for a limited amount of time
> > Is not hard to guess, if it uses an AoR and could be with anonymous URI.
> > Identifies the user if it uses an AoR and doesn't with anonymous URI
> >
> > The protocol (SIP) for retrieving presence, and thus location has the
> > location ruleset as we defined for PIDF-LO, but otherwise does not have
> "no
> > cache" semantics (albeit caching headers is not very interesting in
> SIP).
> 
> You cannot compare presence witht he location-by-reference solution
> since the deployment case is different.
I believe this to be false on its face.  If I give you a sip URI and tell
you a presence server will respond to it including location, then you can
exchange the URI for location, and that is location-by-reference.

You cannot put that cat back in the bag.  A presence URI that reports
location in the PIDF results in location-by-reference.

The idea that you could have a presence URI where the only information
returned in the PIDF that was interesting was location does not need an RFC.
It's obvious, it's allowed, and the anonymized user stuff was created for
this purpose.

Presence is location by reference (it can be identification-by-reference, it
can be happiness-by-reference).  You have a URI, you exchange it for a PIDF.
You are done, stop arguing.


> 
> >
> > Generally, presence systems do have user control of who is allowed to
> access
> > information, including location and identifying information, so I think
> that
> > is covered fairly well.
> 
> Not true in this case.
> 
> Here we have a SIP proxy in the access network doing all the work. You
> can compare it with a SIP-based LIS from the Geopriv-L7 work. This node
> has no clue about your privacy preferrences and does not know your
> identity. This is what we discussed in the past and several proposals
> where made, namely:
> 
> * end host provides privacy preferences (see HELD)
> * end host does not provide privacy preferences since there is no
> PIDF-LO (see RELO).

I don't agree.  A proxy can assert a presence URI in a number of places.
I'm pretty sure, for example, that many carriers intend the P-A-I to be a
presence URI, or (if a tel uri) convertible trivially to a presence URI.

I don't like it, but whether a proxy asserts your presence URI or your
endpoint does, there is no functional difference.  I worry about the issue
of whether the proxy's URI resolves to a PIDF that has the policies you want
asserted.  But that is not a protocol issue.  That is a contract and local
law issue.  The URI and the PIDF have the same capacity to express the users
wishes with respect to identity, location and all the other parts of the
PIDF.

Your carrier's outgoing proxy is perfectly capable of asserting a presence
URI that resolves to a PIDF that represents your policies on your location.

I prefer the endpoint to be the one doing this, because I think there is a
better chance it will get it done right, but that's a pretty soft thing,
having nothing to do with protocols.  The proxy is in the same domain as the
user, and is being trusted by the user to correctly handle its calls.
Putting his location (via presence) is one of the things it is reasonable to
trust the proxy to do.

You could look at this a different way.  If the network determines the user
location, that information belongs to the network.  It would be up to the
network to tell the user, if it wants to.  The user doesn't own the data,
even if it represents his location.  If I take a picture of you, I own the
picture.  Some laws may limit what I can do with it, but it's my data.
Proxy assertion of location is the network telling someone the data it owns.
It's not yours unless the network decides to give it to you, or gives you
control over it.  Again, laws may limit what it can do with the data.
> 
> >
> > Proxy insertion of location, whether by value or by reference has the
> threat
> > of not being as subject to user control, but I think in every case you
> have
> > to trust your provider to do as you wish, whether it is your presence
> > provider or your location provider independent of your presence
> provider,
> > and proxy insertion doesn't fundamentally alter that.  I worry more
> about
> > it, but I don't objectively think it's much different.
> 
> In this case you don't really know the provider and it might not be your
>   provider.
Actually, it has to be (or it wouldn't know your location).  You have the
case of the visited network not being your carrier, but effectively, if you
are roaming on their network, they are your carrier of choice.

> 
> >
> > Now, if there are other location dereferencing systems, they may need an
> > analysis like what you are suggesting, but with respect to SIP Presence,
> as
> > a form of location by reference, I think we have been over the ground
> > sufficiently, and we have RFCs that permit it.  Adding restrictions on
> the
> > Location header, which I propose is useful precisely to allow an
> anonymous
> > presence uri that does not reveal identity is not so great I think.  If
> you
> > don't allow that, you would kind of have to use an AoR, which may be
> > appropriate in some cases, but would not in others.
> 
> The reference might not reveal the identity but what about the identity
> in the PIDF-LO. If you argue that there does not need to be one (or it
> is a faked one) then I am puzzled why it has been a source of major
> confusion in the Geopriv-L7 design team work (and in previous
> discussions about the same subject in Geopriv).
See above.  It's easy to generate a completely random identity.  The
difficulty in the L7 case is how the endpoint identifies itself to the LIS
in order to receive the right location or reference.  Proxy insertion has
the same problem of how it knows which location to assert.  You can't do
proxy insertion of location unless you know FOR SURE where the device is.
We do need text on that, as above.

> 
> >


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip