Subject: [Sip] Routing of calls based on location

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 17:23:44 -0400

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.

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 fact, we would need to use
hop-by-hop security, with transitive trust.  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).

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).

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.

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Jul 2006 10:09:51 +0200

Hi Brian,

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

> call using LoST.  It may be that the UAC itself does this, but it may be

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).

> 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
> 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.

> using SIP for the purpose of location based routing.

   We will specify you
> about the choice of URI construction which is raised in another email I am

I think that this is largely orthogonal issue.

> 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.

> geopriv list, and not copied to either sip or ecrit.

Ciao
Hannes

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