Subject: Re: Verifying that a call goes to a PSAP (Was Re: [Ecrit] Signed LoST mappings)

From: Matt Lepinski <[email-masked]>
Date: Fri, 03 Aug 2007 14:15:41 -0400

James,

What Richard (I believe) proposes in his draft is that the ESRP (acting 
as a B2BUA) add additional "information" (probably in a SIP header) to 
the 200/OK or to a subsequent SIP message (i.e. an UPDATE as in 
connected identity). This "information" (which may be connected 
identity, or may be a signed LoST record, or may be something totally 
different) may then be examined by a proxy (between Alice and the ESRP) 
that cares whether the call is an emergency call. (E.g. a VSP proxy that 
is concerned about fraud.) This proxy will then use this "information" 
to verify that the call is indeed an emergency call and take appropriate 
action, based on local policy. (E.g. If the call is truly an emergency 
call, the VSP may make an entry in a local accounting database that the 
call should be free of charge. Alternatively, if the call is not truly 
an emergency call but is marked with an sos URN, the VSP may take legal 
action against the customer for fraud).

The above "meta proposal" is essentially what is outlined in Richard's 
draft. My question is whether this type of approach to verifying the 
validity of an emergency call is reasonable to continue discussing, or 
whether there is some fundamental reason why a solution that relies on a 
non-INVITE message to determine the validity of an emergency is 
inherently unworkable.

Thanks,
- Matt Lepinski :->

James M. Polk wrote:

> Matt
>
> Looking at this example topology
>
> Alice--INVITE-->Proxy1-->Proxy2-->ESRP/ESInet-->EmSvcsProxy-->PSAP
>
> Alice<--Proxy1<--Proxy2<--ESRP/ESInet<--EmSvcsProxy<--200OK--PSAP
>
> Q#1 - Where is this 200 OK important in your context (for verifying 
> intended destination)?
>
> Q#2 - Why is this important at this point in the topology?
>
> Q#3 - What do you expect the SIP element to do with any indication you 
> are creating here?
>
> Little new can be between Alice and the ESRP, as we're attempting to 
> create a solution with the LEAST amount of changes to SIP --> because 
> the more changes there are, the more complicated the solution is, the 
> less likely it will be implemented right --> which is the goal, right?
>
> The ESRP should be a B2BUA or SBC, so changes behind it towards the 
> PSAP call taker's UA need to highlighted as only being in that part of 
> the topology.
>
> We cannot expect COTS SIP products to do too much, yet I don't believe 
> COTS SIP equipment will be used at the ESRP or between it and the PSAP.
>
>
> At 01:00 PM 7/31/2007, Matt Lepinski wrote:
>
>> I'd like to step back (for a moment) from the discussion of whether 
>> there is a way for a third party to verify that a LoST mapping for a 
>> Taiwanese PSAP is authentic (or authoritative).
>>
>> At a high level Richard proposed that the problem of fruad prevention 
>> (verifying that a call is actually headed to a PSAP) can be solved 
>> more easily if we utilize not just the SIP INVITE but a response to 
>> the SIP INVITE. In particular, if we use Connected Identity (if PSAPs 
>> have appropriate credentials) or Signed LoST Mappings (if LoST 
>> servers have appropriate credentials) or something else (if someone 
>> else has appropriate credentials).
>>
>> Henning provided the following response:
>>
>>> [Richard Barnes:] Note that this level of state (e.g., keeping track 
>>> of all the messages in an INVITE transaction) is useful for things 
>>> like accounting and billing as well, so VSPs may be doing it anyway.
>>>
>>> [Henning Schulzrinne:] This is not the right forum for this 
>>> discussions, but if a VSP relies on such capabilities, they are 
>>> likely to be in (financial) trouble. One of the core assumptions for 
>>> ECRIT is that we don't mess with SIP call flows or create 
>>> emergency-specific call flows.
>>
>> Henning seems to be saying that any mechanism for fraud prevention 
>> which relies on a message other than the SIP INVITE is not useful.
>>
>> Am I interpreting Henning's response correctly?
>>
>> Do others feel that using messages other than the SIP INVITE is not a 
>> useful approach to fraud prevention?
>>
>> - Matt Lepinski :->
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ecrit
>
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 3 Aug 2007 16:34:30 -0400

As I indicated before, it is only workable if SIP behavior is  
modified or restricted. Normal SIP requires no UPDATE, i.e., a  
compliant terminal may not generate such a message. I'd wager that  
most existing IP phones never generate an UPDATE.

Practically speaking, this is all pretty moot if we mainly worry  
about PSTN-destined calls, rather than IP-end-point calls, which are  
currently free in all VSPs I know about. (3G may change this notion,  
so this is not a foregone conclusion.) In the PSTN case, the UAS (=  
PSTN gateway) is controlled by the VSP or a trusted business partner  
and it can use SIP INVITE information to make a determination whether  
a no-charge emergency call is indeed going to a PSTN E.164 number, if  
it has the right information (e.g., location information that it can  
apply LoST on).

Henning

On Aug 3, 2007, at 2:15 PM, Matt Lepinski wrote:

> James,
>
> What Richard (I believe) proposes in his draft is that the ESRP  
> (acting as a B2BUA) add additional "information" (probably in a SIP  
> header) to the 200/OK or to a subsequent SIP message (i.e. an  
> UPDATE as in connected identity). This "information" (which may be  
> connected identity, or may be a signed LoST record, or may be  
> something totally different) may then be examined by a proxy  
> (between Alice and the ESRP) that cares whether the call is an  
> emergency call. (E.g. a VSP proxy that is concerned about fraud.)  
> This proxy will then use this "information" to verify that the call  
> is indeed an emergency call and take appropriate action, based on  
> local policy. (E.g. If the call is truly an emergency call, the VSP  
> may make an entry in a local accounting database that the call  
> should be free of charge. Alternatively, if the call is not truly  
> an emergency call but is marked with an sos URN, the VSP may take  
> legal action against the customer for fraud).
>
> The above "meta proposal" is essentially what is outlined in  
> Richard's draft. My question is whether this type of approach to  
> verifying the validity of an emergency call is reasonable to  
> continue discussing, or whether there is some fundamental reason  
> why a solution that relies on a non-INVITE message to determine the  
> validity of an emergency is inherently unworkable.
>
> Thanks,
> - Matt Lepinski :->
>
> James M. Polk wrote:
>
>> Matt
>>
>> Q#1 - Where is this 200 OK important in your context (for  
>> verifying intended destination)?
>>
>> Q#3 - What do you expect the SIP element to do with any indication  
>> you are creating here?
>>
>> Little new can be between Alice and the ESRP, as we're attempting  
>> to create a solution with the LEAST amount of changes to SIP -->  
>> because the more changes there are, the more complicated the  
>> solution is, the less likely it will be implemented right -->  
>> which is the goal, right?
>>
>> The ESRP should be a B2BUA or SBC, so changes behind it towards  
>> the PSAP call taker's UA need to highlighted as only being in that  
>> part of the topology.
>>
>> We cannot expect COTS SIP products to do too much, yet I don't  
>> believe COTS SIP equipment will be used at the ESRP or between it  
>> and the PSAP.
>>
>>
>>> I'd like to step back (for a moment) from the discussion of  
>>> whether there is a way for a third party to verify that a LoST  
>>> mapping for a Taiwanese PSAP is authentic (or authoritative).
>>>
>>> At a high level Richard proposed that the problem of fruad  
>>> prevention (verifying that a call is actually headed to a PSAP)  
>>> can be solved more easily if we utilize not just the SIP INVITE  
>>> but a response to the SIP INVITE. In particular, if we use  
>>> Connected Identity (if PSAPs have appropriate credentials) or  
>>> Signed LoST Mappings (if LoST servers have appropriate  
>>> credentials) or something else (if someone else has appropriate  
>>> credentials).
>>>
>>>> [Richard Barnes:] Note that this level of state (e.g., keeping  
>>>> track of all the messages in an INVITE transaction) is useful  
>>>> for things like accounting and billing as well, so VSPs may be  
>>>> doing it anyway.
>>>>
>>>> likely to be in (financial) trouble. One of the core assumptions  
>>>> for ECRIT is that we don't mess with SIP call flows or create  
>>> Henning seems to be saying that any mechanism for fraud  
>>> prevention which relies on a message other than the SIP INVITE is  
>>> not useful.
>>>
>>> Do others feel that using messages other than the SIP INVITE is  
>>> not a useful approach to fraud prevention?
>>>
>>> - Matt Lepinski :->
>>>
>>>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 03 Aug 2007 20:22:37 -0400

> As I indicated before, it is only workable if SIP behavior is modified 
> or restricted. Normal SIP requires no UPDATE, i.e., a compliant terminal 
> may not generate such a message. I'd wager that most existing IP phones 
> never generate an UPDATE.

ECRIT is already specifying behaviors for PSAPs in the framework and 
phonebcp.  Requiring them to send an UPDATE (e.g., for 
connected-identity) doesn't seem to onerous.

But using an UPDATE really isn't necessarily needed.  At base, what's 
necessary is a mechanism that allows either the UAC or the PSAP (UAS) or 
maybe a proxy to add the magic dust that shows that a call is an 
emergency call.  Relying on just the INVITE doesn't do that, but (for 
instance) if you allow the magic dust in either an INVITE or a 200, then 
all three cases are supported.  Likewise for an UPDATE.

> Practically speaking, this is all pretty moot if we mainly worry about 
> PSTN-destined calls

That's a valid point, but we do need to accommodate the 3G use case.  My 
3G provider cares very much about charging me for non-emergency calls, 
and I don't expect this to change when IMS comes along.

Speaking of 3G, though, does bring to mind the possibility of an 
out-of-band solution: E.g., the PSAP could send some assertion that says 
the call is an emergency call to all the proxies in the Via header, in 
case they care.  You could do this with a MESSAGE.

--Richard

>> header) to the 200/OK or to a subsequent SIP message (i.e. an UPDATE 
>> as in connected identity). This "information" (which may be connected 
>> different) may then be examined by a proxy (between Alice and the 
>> ESRP) that cares whether the call is an emergency call. (E.g. a VSP 
>> proxy that is concerned about fraud.) This proxy will then use this 
>> "information" to verify that the call is indeed an emergency call and 
>> take appropriate action, based on local policy. (E.g. If the call is 
>> truly an emergency call, the VSP may make an entry in a local 
>> accounting database that the call should be free of charge. 
>> Alternatively, if the call is not truly an emergency call but is 
>> marked with an sos URN, the VSP may take legal action against the 
>> customer for fraud).
>>
>> whether there is some fundamental reason why a solution that relies on 
>> a non-INVITE message to determine the validity of an emergency is 
>> inherently unworkable.
>>
>> Thanks,
>> - Matt Lepinski :->
>>
>> James M. Polk wrote:
>>
>>> Matt
>>>
>>> PSAP call taker's UA need to highlighted as only being in that part 
>>> of the topology.
>>>
>>> believe COTS SIP equipment will be used at the ESRP or between it and 
>>> the PSAP.
>>>
>>>
>>>> prevention (verifying that a call is actually headed to a PSAP) can 
>>>> be solved more easily if we utilize not just the SIP INVITE but a 
>>>> response to the SIP INVITE. In particular, if we use Connected 
>>>> Identity (if PSAPs have appropriate credentials) or Signed LoST 
>>>> Mappings (if LoST servers have appropriate credentials) or something 
>>>> else (if someone else has appropriate credentials).
>>>>
>>>>> track of all the messages in an INVITE transaction) is useful for 
>>>>> things like accounting and billing as well, so VSPs may be doing it 
>>>>> anyway.
>>>>>
>>>> Do others feel that using messages other than the SIP INVITE is not 
>>>> a useful approach to fraud prevention?
>>>>
>>>> - Matt Lepinski :->
>>>>
>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 3 Aug 2007 21:40:49 -0400

This is way beyond the scope of ECRIT.

As I said, the 200 can kind of work, if you assume this magic "I'm a  
PSAP" cert.

None of this works well for unauthenticated calls: There's nobody to  
bill, so you can't just sort out the billing details later and, at  
worst, charge a few cents for a legitimate 911 call. With  
unauthenticated calls, you'd have to recognize the call, and then  
somehow terminate it. (This works within 3G, not in regular SIP  
between two Internet UAs.) If you get a signature/cert you don't  
recognize, the VSP now faces a pretty big liability, as it could be  
accidentally terminating a legitimate emergency call.

As a technical side note, Via headers aren't valid SIP destinations.  
They are just host names. I think it would be helpful if we left the  
SIP engineering to the appropriate working groups.

Henning

On Aug 3, 2007, at 8:22 PM, Richard Barnes wrote:

> ECRIT is already specifying behaviors for PSAPs in the framework  
> and phonebcp.  Requiring them to send an UPDATE (e.g., for  
> But using an UPDATE really isn't necessarily needed.  At base,  
> what's necessary is a mechanism that allows either the UAC or the  
> PSAP (UAS) or maybe a proxy to add the magic dust that shows that a  
> call is an emergency call.  Relying on just the INVITE doesn't do  
> that, but (for instance) if you allow the magic dust in either an  
> INVITE or a 200, then all three cases are supported.  Likewise for  
> an UPDATE.
>
>> about PSTN-destined calls
>
> That's a valid point, but we do need to accommodate the 3G use  
> case.  My 3G provider cares very much about charging me for non- 
> emergency calls, and I don't expect this to change when IMS comes  
> along.
>
> out-of-band solution: E.g., the PSAP could send some assertion that  
> says the call is an emergency call to all the proxies in the Via  
> header, in case they care.  You could do this with a MESSAGE.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 6 Aug 2007 08:33:48 -0400

I agree the 200 would work assuming a recognized cert.  I don't see a big
problem doing that with a PSAP.

I don't see a problem with an answer followed by a forced disconnect if it
came to that, and I agree with Henning that the liability for terminating an
emergency call is large.  I think it could be used for a fraud alert.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, August 03, 2007 9:41 PM
> To: Richard Barnes
> Cc: ECRIT
> Subject: Re: Verifying that a call goes to a PSAP (Was Re: [Ecrit]
> SignedLoST mappings)
>