Subject: [Ecrit] Emergency call marking

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2007 16:29:16 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 12 Sep 2007 16:03:01 -0500

At 03:29 PM 9/12/2007, Richard Barnes wrote:
>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:

shouldn't the simple solution be for said proxy (and all other 
proxies) to simply not provide special treatment to a non-emergency 
SIP request?

In other words, IF a proxy identifies a SIP request as an emergency 
request, provide it whatever treatment is afforded emergency request 
(a local policy decision), ELSE treat as any other SIP request 
(normal treatment).

I don't like the use of the word "verify" in the original email.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2007 17:22:33 -0400

James,

The problem is how the proxy is able to reliably tell which SIP requests 
are emergency SIP requests.  That is, if a proxy is looking at a SIP 
request, how does it verify that the request is an emergency request.

--Richard

James M. Polk wrote:
> shouldn't the simple solution be for said proxy (and all other proxies) 
> to simply not provide special treatment to a non-emergency SIP request?
> 
> request, provide it whatever treatment is afforded emergency request (a 
> local policy decision), ELSE treat as any other SIP request (normal 
> treatment).
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 12 Sep 2007 17:59:41 -0400

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:[email-masked]]
> Sent: Wednesday, September 12, 2007 4:29 PM
> To: ECRIT
> Subject: [Ecrit] Emergency call marking
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2007 19:45:59 -0400

Hi Brian,

> I think we have to relate this to "location hiding". 

That's what I thought, too, but it's not really true: Until LoST routing 
gets done, there's no fraud risk, and whoever does LoST routing already 
has to have access to location (SB or input).  So the real question is 
not how to verifiably mark calls, but how to make sure LoST routing gets 
done in the location hiding use case.  And that's a problem whether 
proxies are worried about verification or not.

> the problem is internal to a carrier ...

I'd be interested to hear more about the validity of these sorts of 
assumptions.  Do you have more detail here?

> same URI that the UA got, and then we are into the location hiding problem.

Remember that whoever does LoST routing has a mapping, and that means 
they have a service boundary.  So if the UA does the routing, it can 
insert the SB by value (if it doesn't have its own location), and a 
proxy can insert a reference to the SB.  SBs are public information, so 
there's no privacy concerns related to these references, and they not 
affected by location hiding.  Note that the proxy could *also* insert a 
reference to the UA's location that could have arbitrary access 
controls, and as long as the ref to the SB was there, the verification 
would work.

So while there is still a connection between location hiding and call 
marking, in that location needs to be available to the entity that does 
the LoST query, making use of service boundaries in this way largely 
decouples the two problems.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 12 Sep 2007 22:40:57 -0400

Hmmm.  Well, so, the idea you're pushing is that if you send the SB, anyone
can verify the PSAP URI by picking a point in the SB and checking the PSAP
URI is the same as that in the Route.

Yeah, I guess.  You might as well send any point inside the SB and avoid
shifting work to the proxy.

I think the notion that a UA can generate a reference to the SB is hard.
Better to get LoST to give you one.

Isn't it easier to just dereference and use that to check the PSAP URI?
What does sending the SB do that dereferencing doesn't?  This really makes
it the location hiding LIS that has to do the work.

There isn't any mechanism to send the SB.

Brian

> Sent: Wednesday, September 12, 2007 7:46 PM
> To: Brian Rosen
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] Emergency call marking
> 
> Hi Brian,
>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 13 Sep 2007 08:28:37 -0400

Richard,

I'm still confused as to the problem you are trying to solve?  Is this a
real problem, as in a proxy operator has brought us requirements?

I'm hanging on the earlier discussion that if a UA does LoST
lookup/emergency call routing, then the VoIP SP can't/won't be able to
'verify' that the session is in fact an emergency call.

What is the down side of a VoIP SP not recognizing an emergency call?  The
customer pays for the call?  (Isn't per-ding billing on a downward trend?)

I'm trying to figure out why we're putting energy into this.

Thanks,

-Marc-  

> That's what I thought, too, but it's not really true: Until 
> LoST routing gets done, there's no fraud risk, and whoever 
> does LoST routing already has to have access to location (SB 
> or input).  So the real question is not how to verifiably 
> mark calls, but how to make sure LoST routing gets done in 
> the location hiding use case.  And that's a problem whether 
> > I do think that there are some problems with downstream 
> LoST routing, 
> > but the problem is internal to a carrier ...
> 
> I'd be interested to hear more about the validity of these 
> sorts of assumptions.  Do you have more detail here?
> 
> > 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.
> 
> Remember that whoever does LoST routing has a mapping, and 
> that means they have a service boundary.  So if the UA does 
> the routing, it can insert the SB by value (if it doesn't 
> have its own location), and a proxy can insert a reference to 
> the SB.  SBs are public information, so there's no privacy 
> concerns related to these references, and they not affected 
> by location hiding.  Note that the proxy could *also* insert 
> a reference to the UA's location that could have arbitrary 
> access controls, and as long as the ref to the SB was there, 
> the verification would work.
> 
> So while there is still a connection between location hiding 
> and call marking, in that location needs to be available to 
> the entity that does the LoST query, making use of service 
> boundaries in this way largely decouples the two problems.
> 
> --Richard
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Sep 2007 17:17:52 -0500

Aren't we conflating at least two, if not three issues here?

What does this thread have to do with the Subject line "Emergency 
call marking"?

"Marking" is the indication within a SIP request that the request is 
an emergency (bound) request.  I'm confused as to what the words 
"verification" and "validate" mean in this context - as used by 
Richard, especially with regard to *any* proxy, not just an ESRP.

Not every proxy has to understand emergency calling. The phoneBCP 
will not become an update to 3261 as mandatory to implement.

I'm even more confused what "Emergency call marking" has to do with 
"location hiding".

If my UA generates a static PSAP URI as an R-URI in an INVITE, the 
request must get to that PSAP (or the ESInet in front of said PSAP) 
with or without location (civic/geo or a locationURI).  If there is 
an ESInet in front of that PSAP, there is an ESRP at the border.  If 
there is a 911 or 112 dialstring or the service urn sos, the 
"Emergency call marking" is achieved by the ESRP by seeing this in 
the request.  That's simple to do.  Local policy will instruct the 
ESRP what to do with the request if there is no such marking.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Sep 2007 09:51:28 -0400

Most proxy servers that are used for most VoIP traffic will not permit an
arbitrary URI in the Request-URI, and they will police a PSAP URI out.  They
won't care a whole lot about To:.

At the moment, they probably would police out a PSAP URI in a Route header.

What we want is to have a marker that stays with the call, all the way to
the PSAP.  We'll have to get the proxies to watch for that marker and let
the call through, but at least some carriers will demand a way to validate
the PSAP URI really is a PSAP URI.  

The sos service URN is a marker.  The question is how to preserve the marker
as far as you can.  With 1-1-2 in the Request URI (as a dial string) it's
not an emergency call unless a proxy recognizes it as an emergency call.  In
lots of systems, that's hard, but its all we got if the endpoint doesn't
recognize it.  The reason its hard is that you have to know the location of
the endpoint to figure out what the dial string(s) to recognize are.

Once recognized, you want it marked with the service urn.

We've vacillated on where the service urn goes, but I think Jonathan's
proposal is best.  That was PSAP URI in a Route header and the service urn
in the Request URI.

The location hiding comes in because of the need to validate the PSAP URI.
I think we're all okay with the notion that we can trust the LoST server to
only have bona fide PSAP URIs in it.  If you can do a query to LoST and get
the URI in the Route header, that is sufficient validation.  There are other
ways to do that, one of which Richard proposed, which let the call through
to the URI but require the PSAP to do something that the proxy would
recognize as only possible from a bona fide PSAP.  That works, but so far,
the only thing proposed needed a global emergency services PKI or something
that was roughly as trusted as the forest guides that propagated information
that could be used to validate the domain.  Either is more spec work and
burdens elements that don't give a hoot about location hiding.  The
advantage of the LoST query idea was it was just words in the BCP, and code
in the LIS that wants to hide (and the same code in the proxy that wants to
validate as it would have for the non-hiding case).

So, yeah, we're conflating, but for what I think is good reason.

Brian
> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, September 14, 2007 6:18 PM
> To: Brian Rosen; 'Richard Barnes'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] Emergency call marking
> 
> > > > I do think that there are some problems with downstream LoST
> routing,
> > > but
> > > > validate that the Route has a valid PSAP URI is a reasonable way to
> go,
> > > but
> > > > reference, then the LIS has to give the proxy location that will
> yield
> > > the

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 18 Sep 2007 09:43:16 +0100

> by the verifier with a listServiceByLocation query).

However, why does this need to be provided with a location?

Whatever system is used to convert a location to a PSAP URI must have a
list of valid PSAP URIs within it. Therefore why can't that system have a
second query interface "is this a valid PSAP URI"?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 18 Sep 2007 04:40:35 -0500

Hi Clive,

I think you are missing some very valuable context here.

Suppose the access network invests, as it will have to, a great deal of
money to location enable itself, so it is somewhat reluctant to just
give location to end-points. It would rather provide a location URI with
a series of service URNs and corresponding destination URIs that can get
location information. Service providers would pay the access provider to
enable their services in the local catchment, not unlike IN services
today.

The issue is to do with how VSPs check the PSAP URI in this case.
Clearly asking the LIS for the location will fail, since the VSP won't
have the necessary credentials. Providing a different interface may
simply result in the LIS, or a system pretending to be a LIS, saying
"yup this is a PSAP URI". The VSP wants to be sure so it knows whether
to charge its subscriber 1 cent a minute for the connection.

My opinion on this remains unchanged, charge the subscriber and debate
the issue later. The alternatives are, don't charge the subscriber and
hope they are being honest, of build a protocol mechanism, maybe in
LoST, to support reverse URI to service URN mappings.

Richard's proposal is midway between these. It says, let the VSP look at
the connected identity and if it is a PSAP don't charge the sub,
otherwise drop the call or charge them.

Cheers
James 

> From: Clive D.W. Feather [mailto:[email-masked]]
> Sent: Tuesday, 18 September 2007 6:43 PM
> To: Richard Barnes
> Cc: ECRIT

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]