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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Wed May 02 2007 - 11:57:45 EDT

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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 02 May 2007 11:57:45 -0400

This archive was generated by hypermail 2.1.8 : Wed May 02 2007 - 11:57:54 EDT