Re: [Geopriv] Routing of calls based on location

Hi Brian,

thanks for raising this issue. Please find my comments below:

Brian Rosen wrote:
> NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO
> GEOPRIV
> 
> The SIP Location Conveyance document anticipates the ability to route a call
> based on the location of the caller.  The original impetus for this is
> emergency calling.  In ecrit, a mechanism has been defined (LoST) that takes
> a service request (in the form of a newly defined service urn) and a
> location and returns a URI.  This mechanism is not limited to emergency
> calling, and could be used for arbitrary location based routing by defining
> new service urns.
> 
> However, this opens up the issue of geopriv privacy concerns because the
> sender does not know the identity of the element (proxy) that will route the
> call using LoST.  It may be that the UAC itself does this, but it may be
> some other intermediary.

Actually, I think we need to be a bit more precise here. There are two 
cases:

(a) End Host runs LoST

(b) Proxy runs LoST

In case of (a) there is no problem. The problem starts with (b).

This was actually one of the reasons why I started the mailing list 
threat about ' Explicit Indication of Location Object  Consumer' (see
http://www1.ietf.org/mail-archive/web/sip/current/msg14356.html).

> 
> If the identity of the intermediary is not known, then protecting the
> location information becomes more difficult, because we cannot encrypt using
> keying material from the intended recipient.

In many cases the identity of the intermediary is known with (b) since 
it is the outbound proxy. The identity of the final recipient is for 
sure not known.

In fact there are at least two intendent recipients here:

* final recipient (i.e., the entity behind the URI returned by LoST)
* proxy that needs to inspect location information in order to perform 
location based routing.

So, in previous mailing list conversations we discussed whether these 
two entities should be treated separately, i.e., by putting two PIDF-LOs 
in the message; one for the intermediary and one for the end point. From 
a security point of view it seems to be a waste because you might not 
know both entities in advance anyway.


   In fact, we would need to use
> hop-by-hop security, with transitive trust.

You might be able to know the location based routing proxy.

What happens if you send a SIP signaling message with a service URN 
parameter to your outbound proxy but it does not have the location-based 
routing capability?

In some sense you need to know already ahead of time whether this 
functionality is support.


   This is what the emergency case
> does, but it also allows no channel security if necessary (usually meaning,
> try it with TLS and if that fails, try again without TLS).

The emergency case is somewhat special because you additionally have to 
consider what happens if none of the security works/can be used.

> 
> We propose to explicitly allow hop-by-hop security when sending location
> using SIP for the purpose of location based routing.



   We will specify you
> MUST use TLS if sending location by reference (and there will be some words
> about the choice of URI construction which is raised in another email I am
> about to send).

I think that this is largely orthogonal issue.

> 
> An important issue that we need to discuss is what "Do Not Distribute" means
> in this case.  We would like it to allow the data to be passed onward.
> Indeed, SIP proxies shouldn't be dropping headers.  We propose that it means
> that it cannot be distributed except that the location header (and body of
> course) is passed as it normally would.

Let us look at the scenario where the end host attaches location 
information.

It would set the policies and then it knows that he is going to request 
an intermediary to perform location-based routing.

In this case preventing further distribution of the PIDF-LO would 
essentially mean that the proxy removes it and sends the message to the 
  URI provided by LoST. Now, it depends on the application whether this 
is a desired functionality but I could imagine it is. I might want to 
find the nearest "something" but I don't want to tell them where I am 
because it is not relevant for them. This does not apply to emergency 
calls but that's a separate story.

In fact there more than just remove the PIDF-LO or keep it. In some 
sense this aspect is similar to the discussed usage of 2 PIDF-LOs in a 
message where one is used for routing and the other one is used for the 
final recipient (both might have a different precision). The proxy might 
also be told to reduce the granularity of location information by the 
user before forwarding the message.

> Note that although this is an issue that concerns the SIP working group,
> because the location conveyance document is a sip document, it really is a
> geopriv issue.  It also affects ecrit, since we are using its protocol
> beyond its initial purpose.  We ask that this discussion be held on the
> geopriv list, and not copied to either sip or ecrit.
> 
> Brian

Ciao
Hannes

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


_______________________________________________
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