[Ecrit] Emergency call marking

[Richard Barnes <[e-mail]>]

I'd like to get back to the topic of emergency call authentication, that 
is, the question of how a third party (e.g., a proxy) that receives an 
INVITE can verify that that INVITE is an emergency call.

----- Short version -----

Problem:
Proxies that provide special considerations to emergency calls want to 
ensure that non-emergency calls (i.e., calls that aren't going to a 
PSAP) don't receive those special considerations.

Solution:

If proxies trust down-stream proxies to do LoST routing, then they can 
assume that non-LoST-routed calls are OK.

If proxies trust the LoST infrastructure, and if entities that do LoST 
routing include the location they used for that routing in the INVITE, 
then any other party can verify that the INVITE is addressed to a PSAP.

----- Long version -----

I'd like to get back to the topic of emergency call authentication, that 
is, the question of how a third party (e.g., a proxy) that receives an 
INVITE can verify that that INVITE is an emergency call.  Note that 
what's being authenticated here whether the call is an emergency call or 
not -- not the identity of either party.  The challenge here is to 
provide assurance to proxies that a call that looks like an emergency 
call is actually routed to a PSAP.

First, some assumptions:
A1. Each proxy trusts downstream proxies to do SIP routing
A2. Each proxy trusts downstream proxies to do LoST routing
A3. Provided that a seeker can query any LoST server he chooses, the 
LoST infrastructure is trusted to provide accurate mappings.
A4. Verification does not need to be a real-time operation

For reference, I'll paraphrase Hannes' email on call marking 
(non-verifiably asserting emergency status).  An INVITE message for an 
emergency call can be of one of three types:
1. Unrecognized (no Service URN or PSAP URI)
2. Recognized, but not routed (Service URN, but no PSAP URI)
3. Recognized and routed (Service URN and PSAP URI)
Endpoints or proxies use dial string recognition to upgrade calls from 
type 1 to type 2, and LoST to upgrade from type 2 to type 3.

INVITEs of type 1 and type 2 do not present a fraud risk:
1. If a proxy receives an INVITE of type 1 and doesn't do dial string 
interpretation (i.e., can't upgrade it to type 2), then it has no idea 
that the call is an emergency call.  Hence, fraud is not an issue, since 
the call has no chance of getting special consideration.
2. If a proxy receives an INVITE of type 2, or upgrades an INVITE to 
type 2, then it's aware that the call claims to be an emergency call. 
So as long as it trusts down-stream proxies to do LoST correctly (A2), 
the proxy is assured that the call will be delivered to a PSAP.

Absent verification, INVITEs of type 3 can be used for fraudulent calls 
by constructing an INVITE that has the same markings as an emergency 
call, but is addressed to a URI that is not a PSAP URI.  So we need to 
define a verification procedure for type 3 INVITES, and assure that all 
type 3 invites have the information required for verification.

One can verify that a URI is a PSAP URI by obtaining it as a <uri> 
element in a LoST mapping.  Given assumptions (A1, A3), an INVITE 
addressed to a URI verified in this way must be addressed to a PSAP. 
More precisely, to verify that an INVITE is addressed to a PSAP:
1. Extract location information and a service URN from the INVITE
2. Do a LoST findService query with that location and URN
3. If the INVITE is addressed to one of the URIs returned in the 
mapping, then the call is verified.
This procedure can be used to verify an INVITE as long as it contains 
location information with good enough accuracy for routing (a URN is not 
strictly necessary, since the set of all available URNs can be obtained 
by the verifier with a listServiceByLocation query).

However, we're talking about type 3 INVITEs, ones that have already been 
LoST-routed.  That means that the entity that did the routing had a LoST 
mapping for this URI, which means that they definitely have a service 
boundary for the PSAP.  If that entity did the lookup to get the 
mapping, they also know what location was used in the findService query. 
So as long as entities that upgrade calls to type 3 (i.e., that do LoST 
routing) always include one of these locations (SB or input) in the 
INVITE, the INVITE will always contain enough information to verify that 
the call is addressed to a PSAP.

To summarize, under the assumptions above,
-- Type 1 and 2 calls cannot be used to fraudulently obtain special 
services given to emergency calls.
-- Entities that do LoST routing MUST include either the location input 
to LoST or the service boundary of the PSAP.
-- Given the above, proxies can always verify whether a call is going to 
a PSAP or not.



Looking at the length of this email, I suppose it should be a separate 
document.  I'll get to work on draft-barnes-ecrit-auth-01...

--Richard























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