Re: [Geopriv] Location in SIP and "retransmission-allowed"

From: Ted Hardie ^lt;hardie@qualcomm.com>
Date: Thu May 03 2007 - 00:23:29 EDT

At 11:00 PM -0400 5/2/07, Henning Schulzrinne wrote:
>As Tom pointed out, re-targeting is a whole different can of worms and largely independent of the LoST issue. This is probably something worth thinking about and is a bit more complicated than you hint at. This is something that the draft should cover, as it is SIP-specific and really not addressed in general GEOPRIV documents, as far as I can tell.
>
>(Most) any SIP proxy, other than outbound, will do retargeting - otherwise, it shouldn't be there...
>
>Let's assume that retargeting would not be allowed if the PIDF-LO prohibits retransmission. This sounds fairly simple, but is tricky in practice.
>
>Is the translation between 'hardie@qualcomm.com' and '12345@phones.qualcomm.com' retargeting in your definition? Or does this depend on an organizational change? In your example, carservice.com is now part of the giantco, so it is not a different organization. Otherwise, any time that an organization has new management, you'd have to fail calls.

I am apparently not being clear enough here. Let me try again. My view is that
if the proxy acts to forward the call without reference to the location, then it is
not acting as a recipient. That is related to the first point Brian raised in the
email that started this thread. The proxy is simply acting as one hop in a
hop-by-hop protocol in its normal manner. From the point of view of location
privacy, it is just passing things along.

If the proxy does use the location, either by reference to some local cache,
a distant LoST server, or related mechanism, to *pick a destination for the
call*, then I think the proxy is no longer acting as pass-through from the
point of view of location privacy. At that point, all of the location privacy
rules have to be considered. We need to make sure that the vocabulary
of those rules is rich enough to allow users to permit that when they wish
to allow it and to forbid it when they do not. Overloading "retransmission=no"
eliminates needed semantics, in my opinion.

I believe this is relatively easy to express ("If a proxy uses the location
to route the request, it must have permission to do so, expressed by
retransmission="routing-permitted" or retransmission="yes").

This does not eliminate any potential privacy concerns that may exist
when SIP's normal behavior would cause the location to go to someone
surprising to the end user. I agree with your points that this would
require more, probably the initiating user encrypting the location
so that only the original recipient can read it. If the original recipient
sold the key with the business, then even that bet is off.

>In this case, I actually sympathize with your desire to prohibit redistribution by call routing (although this has nothing to do with whether the call routing is based on location or, say, just the From or To header), as I expected to send my LO, with identity, to X and it's going to Y. The hard part will be defining when X is not equivalent to Y. An expansive definition will mean that no call that has retransmission=no will succeed and thus, people will pretty quickly have to give up on that flag if they want location-bearing calls to go anywhere.
>
>There are some clear cases that I think we can easily consider retransmission: If company X sends a call to some totally unaffiliated company Y, this is clearly retransmission. It gets trickier for private individuals. What if I forward my son's location-bearing calls to the dinner party I'm at? How is my phone supposed to know whether that's an ok thing or not?
>
>Usually, privacy policies list all the affiliates and subsidiaries that a company considers to be part of the same organization, so this is not a new problem.
>
>It is obviously easier if I just agree with your opinion. I've tried to make technical arguments why the approach doesn't work and is likely to lead to either a false sense of privacy or call failures, or likely both, with lots of additional complexity. As far as I can tell, you have not been able to provide a single example that actually works once one goes through the details. Protocol behavior that is under-specified, but is lawyer-bait, just doesn't seem like a good idea to me.

I am more than willing to do the work to make specify this correctly. I believe
we are actually disagreeing on the goals. I believe that this level of user control
is both needed and consistent with GEOPRIV's charter. Your responses seem to
indicate that you do not. Your opinion appears instead to be that it is not
needed because proxy can use a mechanism to route that does not require it
reveal the identity on whose behalf it made the query. I don't think that eliminates
the need, for many of the same reasons Richard has already put forward. If
I have misunderstood you and we do agree on the goals, then I have misunderstood
how you can achieve them while overloading retransmission=no. If that is the
case, please restate that for me.
                                thanks,
                                        Ted

>Henning
>
>
>On May 2, 2007, at 12:44 PM, Ted Hardie wrote:
>
>>At 9:04 AM -0400 5/2/07, Henning Schulzrinne wrote:
>>>Another thought on this topic, which seems to have gotten lost. In the end, this is all about trust. We sometimes have the notion that SIP proxies are kind of like routers, operated by random entities that we don't control. However, that's a clear misunderstanding of how SIP request routing works. Those familiar with SIP will have seen the SIP trapezoid picture, consisting of a proxy in the outbound domain (typically, my VSP) and in the destination domain.
>>>
>>>For the topic at hand, as I noted, there are two cases:
>>>
>>>(1) The destination URL is a service URN. If not resolved by the UA, it needs to be resolved by the very first (outbound) proxy. Thus, this proxy needs to do a location-based lookup. There simply is no choice other than failing the call, assuming that there is no worldwide catch-all call center for that service. Thus, any privacy indication in this case is simply a waste of time, since you might as well have a "fail this call, please" flag.
>>
>>Henning, I think you're missing the possibility that the call may get transferred
>>or otherwise retargeted. I make a call to local@carservice.example. They've
>>been bought, and my call is now forwarded to dispatch@giantco.example,
>>which wants to do location based routing. The user might be fine with
>>it going to the original recipient and even fine with the forwarding, but
>>not okay with the location based routing that occurs as a result.
>>
>>I am sorry if you feel this is not a compelling example, but I don't think
>>you can guarantee that this semantic (the "real no") is never needed.
>>I think Richard's notion of something beyond a binary "routing permitted"
>>flag is probably a good one, since it gives extensibility, but I'm fine
>>with "routing permitted" if we want to do one thing and stop.
>>
>>I'm not fine with us breaking one of the core semantics of GEOPRIV,
>>and your attempts to mock that position simply won't convince me.
>>We can go around and around, but that's probably not productive.
>>There is an easy way past this. Let's take it and move on.
>>
>> regards,
>> Ted
>> Ted
>>
>>_______________________________________________
>>Geopriv mailing list
>>Geopriv@ietf.org
>>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 2 May 2007 21:23:29 -0700

This archive was generated by hypermail 2.1.8 : Thu May 03 2007 - 00:23:53 EDT