|
|
I don't think that reliability is necessarily a discriminator in this
case: If you send the PSAP's location/service area in a 200 and the 200
doesn't get there, you've got other problems above and beyond VSP
verification.
--Richard
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.
Brian
-----Original Message-----
From: Richard Barnes [mailto:rbarnes@xxxxxxx]
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).
--Richard
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.
-andy
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
on
every emergency call.
The basic idea has merit, but the details don't work for me.
Brian
-----Original Message-----
From: Richard Barnes [mailto:rbarnes@xxxxxxx]
Sent: Thursday, June 28, 2007 12:30 AM
To: James M. Polk
Cc: ECRIT
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
many
models that could be used: Authenticators could be conveyed in a 200,
or
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
intended
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
authentication
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:
One
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
call,
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).
--Richard
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
solve
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,
after
all, is in a much better position to authenticate itself than the
UAC
is to authenticate it. This authentication could take several
forms:
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
in
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
sign
a 200 response with it's key).
Both of these can be done with protocols that are already released
or
in process: Option 1 by including a GML or PIDF-LO document in the
200
response (possibly indicated by a Geolocation: header), and Option 2
with S/MIME or connected-identity.
Humbly submitted,
--Richard
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|