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

From: "Pailer Rudolf" <[email-masked]>
Date: Thu, 3 May 2007 09:39:29 +0200

Hello!

I have followed this dicussion with interest and would like to point out that, in my opinion,  protecting the privacy of location information can only be achieved ent-to-end (e.g. by encryption).
Our research group (www.ftw.at) has some experience with location based services, and we identified the SIP Presence framework as the best way to transport location data in SIP. SIP Presence works on a strict SUBSCRIBE/NOTIFY pattern, where it is the task of the presentity to authenticate and authorise the watcher. Furthermore location data is transported in the SIP message body and can easily be encrypted. We have recently submitted an Internet Draft (http://www.ietf.org/internet-drafts/draft-pailer-locpres-00.txt) in that respect. In this draft we furthermore propose to place 'location presence' in an own SIP event package, that extends conventional presence, but allows processing of 'location presence' in dedicated presence nodes.

regards
Rudolf

-----Ursprüngliche Nachricht-----
Von: Richard Barnes [mailto:[email-masked]] 
Gesendet: Mittwoch, 02. Mai 2007 17:58
An: Henning Schulzrinne
Cc: GEOPRIV
Betreff: Re: [Geopriv] Location in SIP and "retransmission-allowed"

Henning,

The point of GEOPRIV is to provide a format for expressing privacy 
preferences.  The semantics indicated by that format is thus a central 
concern of the working group.  Call it theology if you want, but that's 
our job.

My point in previous emails is that according to existing 
specifications, retransmission-allowed=no means that you can't do an 
arbitrary LoST query.  You need to ensure that the LoST query won't 
cause the location information to be transmitted to a third party, 
where, e.g.,  the LoST emergency mapping infrastructure is counted as a 
third party.  Thus, a LO included via a Geolocation header with 
retransmission-allowed=no would prevent that location from being used 
for some (perhaps most) LoST queries.  This would cause calls such as 
your case (1) to fail, essentially because the UAC would have 
constructed a contradictory message. (Note, however, that this could 
still be overridden in limited cases, e.g., by phonebcp.)

How do you want to change this situation?

0. Instruct proxies to ignore the value of retransmission-allowed for 
locations included via a Geolocation header.

[RLB] This would standardize behavior inconsistent with RFC 4119. 
Nothing requires Location Recipients to abide by privacy rules, but we 
shouldn't require them to break privacy rules either.  This behavior is 
only suitable for special situations, e.g., emergency calling.

1. Revise the meaning of retransmission-allowed=no to indicate that the 
location may be used for LoST, no matter where it gets sent.

[RLB] As I've said before, this is an application-specific modification 
to a field that is intended to be application-agnostic.

2. Require that a location included in a Geolocation header have 
retransmission-allowed=yes.

[RLB] This is a problem because locations conveyed in a Geolocation 
header can be Received by both a proxy and the UAS.  The endpoint might 
want the proxy to send the location on for routing, but the UAS not to 
transmit it, and the UAC would need to include two separate locations to 
allow this.

3. Add an additional usage-rules field to indicate explicit permission 
to do LoST.

[RLB] Minimal overhead, minimal complexity; maximal clarity.

4. Something else?

--Richard

Henning Schulzrinne wrote:
> We are now clearly in the realm of theology, as we're trying to do 
> exegesis on ancient documents which may or may not have been divinely 
> inspired.
> 
> I'd much rather discuss real privacy threats and real engineering 
> mechanisms to protect user privacy.
> 
> My general concern is that adding a 'do not location-route' means that 
> almost all calls that need such routing will fail. I've laid out the 
> failure cases earlier, and it would be helpful if you could address those.
> 
> Thus, in the vast majority of cases, this flag will have no effect 
> except causing call failures. The only alternative is that calls will 
> get routed to a global call center. I fail to see how that has any 
> positive effect on user experience or privacy, given that the call taker 
> in some faraway place will see the location information, based on the 
> rules. At best, you get to talk to a lady in North Dakota who will say 
> "You want pizza in Brooklyn? Let me look this up - I'll transfer you 
> after I consult my directory."
> 
> I will note that for the case (2) I mentioned, the LoST hierarchy is 
> indeed operated by the same logical organization that is being addressed 
> by the request URL. In my examples, PizzaHut or the regional emergency 
> network. (In case (1), a negative flag will always cause call failures, 
> so it's not terribly interesting.)
> 
> Thus, based on your "this is about organizations, not wires" notion, 
> these would be permitted without a flag. Am I getting this right?
> 
> Thus, it would be helpful if you could describe cases, based on how SIP 
> routing really works, where the flag would make a real privacy 
> difference and not just a call failure.
> 
> Henning
> 
> On May 2, 2007, at 10:23 AM, Richard Barnes wrote:
> 
>> Perhaps it would help if we were more concrete.
>>
>> Quoth RFC 4119:
>> "When the value of this [the retransmission-allowed] element is 'no', 
>> the Recipient of this Location Object is not permitted to share the 
>> enclosed Location Information, or the object as a whole, with other 
>> parties."
>>
>> The critical part of this criterion for this discussion seems to be 
>> the definition of "parties": Is a party a process, a box, a LAN, a 
>> trust domain, a legal entity?  These distinctions are what I suppose 
>> you're referring to as "angels-on-a-pin" distinctions.  But I also 
>> think that they're largely irrelevant to this discussion, because 
>> allowing a general LoST query will hand location to another "party" by 
>> any reasonable definition.
>>
>> First, let me say that there are situations in which 
>> retransmission-allowed=no WOULD allow for location-based services.  
>> For instance, if a telco were considered a party (as it is a legal 
>> Party to a EULA), the location could be passed around within the telco 
>> for whatever purposes.
>>
>> However, focusing for the moment on the emergency case: When a proxy 
>> does a LoST lookup, the query progresses through the LoST 
>> infrastructure as described in the mapping architecture.  In the base 
>> case, this means that the "enclosed Location Information" is 
>> transmitted all the way to the authoritative LoST server.  Which means 
>> that in order to interpret retransmission-allowed=no as allowing LoST 
>> queries, you'd have to consider every authoritative LoST server as 
>> part of the same "party". This hardly seems like a reasonable 
>> definition of "party".
>>
>> So it seems clear that retransmission-allowed=no, with the semantic 
>> given in RFC 4119, disallows LoST queries in general.  With that in 
>> mind, what is your proposed modification?
>>
>> --Richard
>>
> 
> 

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

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