Subject: [Ecrit] Security Threat in Emergency Call System

From: "Raman Chan" <[email-masked]>
Date: Fri, 12 Sep 2008 10:43:24 +0800

Hi,
In RFC5069,section 6.
  "the service provider's call routing entity MUST verify
     that the destination address (e.g., SIP Request-URI) presented in the
     call signalling is that of a PSAP. "

How to judge a URI is a PSAP-URI at the proxy side?
Is there any protocol to verify the URI, or the proxy just also issue
another LoST query and compare the result URI with request-URI?

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 12 Sep 2008 08:47:50 +0300

You would use LoST again to compare it. 
We have discussed reverse lookup mechanisms in the past as well but they
seem to introduce complexity that isn't really necessary 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Raman Chan
	Sent: 12 September, 2008 05:43
	To: [email-masked]
	Subject: [Ecrit] Security Threat in Emergency Call System

	Hi,
	In RFC5069,section 6.
	  "the service provider's call routing entity MUST verify
	     that the destination address (e.g., SIP Request-URI)
presented in the
	     call signalling is that of a PSAP. "
	 
	How to judge a URI is a PSAP-URI at the proxy side?
	Is there any protocol to verify the URI, or the proxy just also
issue another LoST query and compare the result URI with request-URI?
	 
	Thanks
	Raman

---

From: "Raman Chan" <[email-masked]>
Date: Fri, 12 Sep 2008 14:31:17 +0800

Ok,let't assume this scenario:
I live in CityA,and the city's PSAP URI is [email-masked]
My SIP client issued LoST query got the result and cached the URI.
Some time later, I went to CityB,this city's PSAP URI is [email-masked]
When I make emergency call,the LoST query expire due to some matter,
the client have to use the cached URI,
so the SIP-Invite contains
Request-URI:[email-masked]<[email-masked]>and
location of CityB,
the VSP'proxy make LoST query with locaiton of CityB,get the URI
[email-masked],
the proxy may reject my emergency call.

Thanks
Raman

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 12 Sep 2008 16:28:04 -0500

Raman

I'm pretty sure, pragmatically, there will be another LoST query 
(based on the location given) within the signaling path to the actual 
PSAP.  This would yield the correct results, and the SIP request 
would go towards that URI, instead of to PSAP_a.

That said, how did your SIP client know it moved to the psap_b 
jurisdiction?  Probably because it performed a LoST query to learn 
the cachable PSAP URI for here your SIP client now is, in case you 
have to call for emergency assistance.  This becomes the cached value 
(overwriting what you previously had in your SIP client as psap_a's 
URI).  When you make an urn sos call, your perform LoST again, 
seeking the freshest URI based on your location.  The fallback is to 
the psap_b URI you loaded when you moved to the new city (i.e., cityB).

Hope this helps.

James

At 01:31 AM 9/12/2008, Raman Chan wrote:
>I live in CityA,and the city's PSAP URI is 
><mailto:[email-masked]>[email-masked]
>Some time later, I went to CityB,this city's PSAP URI is 
><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>Request-URI:[email-masked] 
>and location of CityB,
><mailto:[email-masked]>[email-masked],
>On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) 
><<mailto:[email-masked]>[email-masked]> wrote:
>        From: <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]] On
>Behalf Of ext Raman Chan
>        To: <mailto:[email-masked]>[email-masked]

---

From: "Raman Chan" <[email-masked]>
Date: Tue, 16 Sep 2008 17:17:26 +0800

James
Let's consider this extreme scenario:
My SIP client learn the latest location(CityB) from LIS successfully,
but the LoST query failed for quite a long-period.
The fallback is still to the psap_a URI I loaded when I am in CityA.

Of course,proxy can do the LoST query again,and the proxy rewrite the PSAP
URI which was supplyed  by SIP client.

In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST
mapping,so why we let the SIP client do this process?
Thanks
Raman

On Sat, Sep 13, 2008 at 5:28 AM, James M. Polk <[email-masked]> wrote:

> Raman
>
> I'm pretty sure, pragmatically, there will be another LoST query (based on
> the location given) within the signaling path to the actual PSAP.  This
> would yield the correct results, and the SIP request would go towards that
> URI, instead of to PSAP_a.
>
> jurisdiction?  Probably because it performed a LoST query to learn the
> cachable PSAP URI for here your SIP client now is, in case you have to call
> for emergency assistance.  This becomes the cached value (overwriting what
> you previously had in your SIP client as psap_a's URI).  When you make an
> urn sos call, your perform LoST again, seeking the freshest URI based on
> your location.  The fallback is to the psap_b URI you loaded when you moved
> to the new city (i.e., cityB).
>
> Hope this helps.
>
> James
>
>> I live in CityA,and the city's PSAP URI is <mailto:[email-masked]>
>> [email-masked]
>> Some time later, I went to CityB,this city's PSAP URI is <mailto:
>> [email-masked]>[email-masked]
>> so the SIP-Invite contains <mailto:[email-masked]<[email-masked]>
>> >Request-URI:[email-masked] <[email-masked]> and
>> location of CityB,
>> the VSP'proxy make LoST query with locaiton of CityB,get the URI <mailto:
>> [email-masked]>[email-masked],
>>       From: <mailto:[email-masked]>[email-masked][mailto:
>> [email-masked]] On
>> Behalf Of ext Raman Chan

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 16 Sep 2008 13:37:53 +0300

You are right that the proxy has to be capable of doing the LoST query
for cases where the clients don't support LoST or in those cases where
VoIP providers care about the fraud case. 

Having LoST support on the end host is useful for obtaining the
emergency services numbers, for validating civic addresses, for learning
about PSAPs in enterprise networks, campuses, etc. Note that not
everyone cares about the fraud case as with many VoIP offerings today
this wouldn't really be fraud as charging isn't done on a call-by-call
basis. 

Additionally, there is the deployment aspect: Deploying LoST on the end
point is simpler when combined with a DHCP-based LoST discovery
mechanism as you don't need to create a global LoST mapping database.

Which specific deployment streams wil be favored is somewhat hard to
tell at this point in time. We will see but the protocol was intentially
designed to be flexible and can therefore be used in different settings.

Ciao
Hannes

	James 
	Let's consider this extreme scenario:
	My SIP client learn the latest location(CityB) from LIS
successfully,
	but the LoST query failed for quite a long-period.
	The fallback is still to the psap_a URI I loaded when I am in
CityA.
	 
	Of course,proxy can do the LoST query again,and the proxy
rewrite the PSAP URI which was supplyed  by SIP client.
	 
	In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the
LoST mapping,so why we let the SIP client do this process?
	Thanks
	Raman

	On Sat, Sep 13, 2008 at 5:28 AM, James M. Polk
<[email-masked]> wrote:

		Raman
		
		I'm pretty sure, pragmatically, there will be another
LoST query (based on the location given) within the signaling path to
the actual PSAP.  This would yield the correct results, and the SIP
request would go towards that URI, instead of to PSAP_a.
		
		That said, how did your SIP client know it moved to the
psap_b jurisdiction?  Probably because it performed a LoST query to
learn the cachable PSAP URI for here your SIP client now is, in case you
have to call for emergency assistance.  This becomes the cached value
(overwriting what you previously had in your SIP client as psap_a's
URI).  When you make an urn sos call, your perform LoST again, seeking
the freshest URI based on your location.  The fallback is to the psap_b
URI you loaded when you moved to the new city (i.e., cityB).
		
		Hope this helps.
		
		James 

			

			My SIP client issued LoST query got the result
and cached the URI.
			
			Some time later, I went to CityB,this city's
PSAP URI is <mailto:[email-masked]>[email-masked] 

			When I make emergency call,the LoST query expire
due to some matter,
			the client have to use the cached URI,
			
			so the SIP-Invite contains
<mailto:[email-masked]
<mailto:[email-masked]>
>Request-URI:[email-masked]
<mailto:[email-masked]>  and location of CityB,
			the VSP'proxy make LoST query with locaiton of
CityB,get the URI <mailto:[email-masked]>[email-masked], 

			Thanks
			Raman

			On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig,
Hannes (NSN - FI/Espoo)
<<mailto:[email-masked]>[email-masked]> wrote:
			You would use LoST again to compare it.
			We have discussed reverse lookup mechanisms in
the past as well but they
			seem to introduce complexity that isn't really
necessary
			
			Ciao
			Hannes

			      From:
<mailto:[email-masked]>[email-masked]
[mailto:[email-masked]] On 

			Behalf Of ext Raman Chan

			      Subject: [Ecrit] Security Threat in
Emergency Call System

			      Hi,
			      In RFC5069,section 6.
			        "the service provider's call routing
entity MUST verify
			           that the destination address (e.g.,
SIP Request-URI)
			presented in the
			           call signalling is that of a PSAP. "
			
			      How to judge a URI is a PSAP-URI at the
proxy side?
			      Is there any protocol to verify the URI,
or the proxy just also
			issue another LoST query and compare the result
URI with request-URI?
			
			      Thanks
			      Raman

---

From: Marc Linsner <[email-masked]>
Date: Tue, 16 Sep 2008 08:08:39 -0400

Raman,

>  
> In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,so
> why we let the SIP client do this process?

A SIP proxy is not a required element.  When there is no proxy used, the UA
must be able to perform a LoST query.

-Marc-