ecrit@ietf.org
[Top] [All Lists]

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

Subject: Re: Verifying that a call goes to a PSAP Was Re: [Ecrit] Signed LoST mappings
From: "James M. Polk"
Date: Tue, 31 Jul 2007 13:23:35 -0500
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
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

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