RE: [Ecrit] Emergency call marking

["Brian Rosen" <[e-mail]>]

I think we have to relate this to "location hiding".  While the notion that
a proxy wants to know that a call purporting to be an emergency call is
indeed an emergency call is useful independent of location hiding, I think
the location hiding problem interacts with this problem so much that the
solutions for both need to be forged at the same time.

I do think that there are some problems with downstream LoST routing, but
the problem is internal to a carrier (like, they don't allow non telephone
number URIs for anything).  I guess that means it's not relevant to the
discussion, but we might make sure of that.

Generally, I think that verification by looking up location via LoST to
validate that the Route has a valid PSAP URI is a reasonable way to go, but
you can see that if that is the case, and the location in the call is a
reference, then the LIS has to give the proxy location that will yield the
same URI that the UA got, and then we are into the location hiding problem.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Wednesday, September 12, 2007 4:29 PM
> To: ECRIT
> Subject: [Ecrit] Emergency call marking
> 
> 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


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