[email protected]
[Top] [All Lists]

Re: [Ecrit] Location hiding: VSP verification by UAS

Subject: Re: [Ecrit] Location hiding: VSP verification by UAS
From: "James M. Polk"
Date: Fri, 29 Jun 2007 13:27:01 -0500
At 11:10 PM 6/28/2007, Richard Barnes wrote:
To be a little more concrete, if the authenticator (location/sb or Identity header) is going to be carried in the 200/OK, then there is no change required to the standard INVITE message flow. The proxy simply observes the 200 as it passes by, and any action it takes based on the authenticator is external to that transaction.

A caller sends an INVITE to a PSAP (regardless of how many servers it goes through, it's destination is towards the PSAP - even if the R-URI is changed). In other words, it's e2e.

Sure. But the response will still go back through the proxies in the Record-Route chain, so if a proxy wants to verify, it just has to add itself into the Record-Route. The 200 will travel e2e, but the proxy will get to see it and get the authenticator from it.

A 200OK to the INVITE is destined for the caller's UAC, not anywhere else - though servers can view unencrypted message bodies if location is LbyV.

This is just an argument to put the authenticator in a header so that proxies can see it. Makes sense to me.

I think also that if you build a PIDF-LO for the coverage area of a PSAP, you aren't going to use civic, as I don't think PSAP boundaries are absolutely limited to a defined city or county perimeter. ...

This is a good point, but I think there are ways around it. Using connected-identity instead of LoST as an authenticator is one. Even if you do use LoST to authenticate the call, then all the PSAP really needs to provide is a single location in its service area; presumably the location of the PSAP will suffice in a lot of cases. Alternatively, the message could contain no location at all, and carry an service boundary reference that could be used to get the location to do the verification.

This is part of the reason (but not specifically about PSAP boundaries) that location is not to be in SIP responses. This is part of section 5.2 UAS Behavior of Conveyance.

I don't really see the harm here.

Conveyance is written (now) as a general purpose mechanism for conveying location, as such, there are no exceptions made because the UAS is a PSAP, even for responses. As stated, location cannot be in responses from any UAS according to the text in Conveyance -08.

I guess the risk is that the PSAP puts in a location that the VSP can't understand,

the risk is that any other UAS can do what the PSAP UAS can do, if Conveyance says location can be in responses.

but it seems like you could write the phonebcp in such a way as to constrain this, e.g., "the value in the Geolocation header MUST be a cid URI" or "MUST be an HTTP URI". Even if there is an error with the Geolocation value, the risk is mostly that the call won't authenticate and the call gets handled as a non-emergency call.

The larger concern is that there is an error with the SIP response, which cannot be reacted to, so the UAS sender will never know it is causing the problem by including location in the response.

This seems like a small risk, and one that could be addressed in the phonebcp (e.g., "VSPs MUST NOT terminate unverifable emergency calls, but MAY choose to handle them as they would non-emergency calls").

(As a general point, I don't see anything in section 5.2 that forbids putting Geolocation into a response, and Table 1 explicitly indicates that Geolocation can be carried in responses.

Table 1 has an 'R' in the 'where' column, which means "not to be in responses", according to the rules of RFC 3261. Section 5.2 of Conveyance says "A UAS MUST NOT send location in a response message..."

both are pretty clear

We should move any further debate on this to another forum, though.)

indeed, as this is a SIP protocol issue, not an ECRIT issue


you've got other problems above and beyond VSP verification.


Brian Rosen wrote:
To get the location of the PSAP, you need an UPDATE, with the PSAP doing the
update and becoming the UAC because it's reliable.  Conveyance is defined
from UAC to UAS only, for this, among other reasons.
-----Original Message-----
From: Richard Barnes [mailto:[email protected]]
Sent: Thursday, June 28, 2007 9:36 AM
To: Andrew Newton
Cc: Brian Rosen; 'James M. Polk'; 'ECRIT'
Subject: Re: [Ecrit] Location hiding: VSP verification by UAS

Right.  In either cases, the VSP would be free to consider a call
unverified if no authenticator were presented after a certain period
(this period would be good to specify in a BCP).


Andrew Newton wrote:
I don't see how an UPDATE helps.  And the endpoint can simply not issue
the UPDATE to get around the verification.

I think Richard's proposal has legs.


On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote:

We would have to do it with an Update.

I am uncomfortable with this idea, as it complicates the message flow
every emergency call.

The basic idea has merit, but the details don't work for me.


-----Original Message-----
From: Richard Barnes [mailto:[email protected]]
Sent: Thursday, June 28, 2007 12:30 AM
To: James M. Polk
Subject: Re: [Ecrit] Location hiding: VSP verification by UAS

Hi James,

I need to see each proposed message flow.
I was proposing more the conceptual flow of the UAS providing the
authentication information than a specific message flow.  There are
models that could be used: Authenticators could be conveyed in a 200,
in a separate UPDATE transaction (as in connected-identity).

SIP is an e2e protocol, and a
200Ok to an INVITE means the INVITE was accepted as is - and is
to travel all the way back to the original UAC. SIP doesn't error
responses, which is what I feel you are proposing if the
fails (within a VSP proxy).
I don't think that it's necessarily within the purview of ECRIT to
specify the behavior that results from a failed authentication.  In
fact, I expect that this behavior will vary widely from VSP to VSP:
VSP might allow the call to proceed normally, but start billing for it
after the authentication fails.  Another might use a B2BUA that it
inserted in the path to kill the call.  Et cetera.

The essential thing is that allowing the UAS to provide authenticators
allows the PSAP to vouch for the fact that a call is an emergency
regardless of how location is provisioned.  What the VSP chooses to do
with that information is a local decision (though maybe we could make
some non-normative recommendations).


At 08:39 PM 6/27/2007, Richard Barnes wrote:
So, the "location hiding" problem is really two problems: When the
access network provisions location in a way that the endpoint can't
get the location,
(1) How does the endpoint or VSP route and emergency call? and
(2) How can a VSP verify that a call is an emergency call?

To date, solutions to the second problem have focused on performing
this verification based on information in the INVITE.  In a location
hiding context, this approach runs into the problem that in order to
use LoST to verify the To: URI, either the UAC, the VSP, or a LoST
server has to dereference the location, and none of these is
necessarily authorized to do so.

On the other hand, I think the second problem is pretty easy to
if the VSP is willing to transmit the INVITE and allow the UAS to
provide evidence that the call is an emergency call.  The PSAP,
all, is in a much better position to authenticate itself than the
is to authenticate it.  This authentication could take several
1. If VSPs are willing to trust the LoST infrastructure, the PSAP
could include its service area in its 200 response; the VSP would
verify by performing a LoST query with the location and service URN
the SIP traffic, and compare the <uri> element in the resulting
mapping to the To: address in the INVITE transaction.

2. If PSAPs have credentials, then the PSAP could use
connected-identity to assert its identity (or just use S/MIME to
a 200 response with it's key).

Both of these can be done with protocols that are already released
in process: Option 1 by including a GML or PIDF-LO document in the
response (possibly indicated by a Geolocation: header), and Option 2
with S/MIME or connected-identity.

Humbly submitted,

Ecrit mailing list
[email protected]

Ecrit mailing list
[email protected]

Ecrit mailing list
[email protected]

Ecrit mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>