Subject: [Sip] The emergency services routing use case

From: [email-masked]
Date: Wed, 19 Mar 2008 21:30:38 -0500

In regard to this use case in draft-rosenberg-sip-ua-loose-route-02.txt:

   2.6.  Emergency Services

   Another problem that arises from Request-URI rewriting is with
   emergency services for VoIP.  A key requirement of systems supporting
   emergency calling is that the SIP INVITE request for an emergency
   call be 'marked' in some way that makes it clear that it is an
   emergency call, so that it can receive priority treatment
   [I-D.ietf-ecrit-requirements].  However, such a marking needs to be
   done in a way that it cannot be abused by attackers seeking to get
   special treatment for non-emergency calls.  The solution for this is
   that the marking needs to be the target address of the request
   itself, which would unambiguously identify an emergency services
   calltaker as the target.

Implicitly, an additional requirement is the ability to do non-trivial
routing and fowarding of the emergency request, that is, where one SIP
agent could provide routing instructions to downstream SIP agents.  In
a perfect world, a proxy could route locally-originating emergency
requests to any specified SIP URI, based on local policy regarding
routing of emergency requests.

Unfortunately, neither draft-rosenberg-sip-ua-loose-route,
draft-holmberg-sip-target-uri-delivery, nor History-Info solves this
problem.  The problem is fundamental:  We desire the *routing* of the
message to be controlled by one element of the request, while the
*priority* is controlled by a different element, the alleged ultimate
destination ("urn:service:sos").  But such a split automatically
allows a malicious user to take advantage of emergency prioritization
for his own use.

As proposed, a message would have "routed emergency service" in one of
the following ways.  (We assume that sip:[email-masked] is the
emergency services address.  In North American usage, an emergency
services operation is called a "PSAP", "Public-Safety Answering
Point".)

    INVITE urn:service:sos SIP/2.0
    From: xxx
    To: xxx
    Route: <sip:[email-masked];lr>

    INVITE sip:[email-masked] SIP/2.0
    From: xxx
    To: xxx
    Target: urn:service:sos

    INVITE sip:[email-masked] SIP/2.0
    From: xxx
    To: xxx
    History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
	    <sip:[email-masked]>;index=2

Unfortunately, all of mechanisms can be exploited (in the same way)
for nefarious purposes:

    INVITE urn:service:sos SIP/2.0
    From: xxx
    To: xxx
    Route: <sip:[email-masked];lr>

    INVITE sip:[email-masked] SIP/2.0
    From: xxx
    To: xxx
    Target: urn:service:sos

    INVITE sip:[email-masked] SIP/2.0
    From: xxx
    To: xxx
    History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
	    <sip:[email-masked]>;index=2

By hypothesis, all of these requests are intended to be routed to
sip:[email-masked] with emergency priority, before allegedly
being forwarded to the correct PSAP destination.

Dale
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Mar 2008 15:28:41 -0500

Dave

I believe the To: field is always supposed to be urn:service:sos, 
regardless of the choice in how to do this.  I don't know if this 
helps the point you're making...

James

---

From: [email-masked]
Date: Thu, 20 Mar 2008 21:38:35 -0500

From: "James M. Polk" <[email-masked]>

   Dave

"Dale"

I don't think people expect the To field to control either the routing
or the prioritization, so I was being lazy about its value.

Dale

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Mar 2008 23:47:11 -0500

>    From: "James M. Polk" <[email-masked]>

oops, sorry

>or the prioritization, so I was being lazy about its value.

fair - but this could be something to check against in most cases, right?

---

From: [email-masked]
Date: Fri, 21 Mar 2008 10:07:47 -0500

It would guard against error, but not fraud.  The problem is that
Jonathan's observation is correct:  To prevent fraud, prioritization
must be controlled by the same datum that controls routing.

Dale

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 21 Mar 2008 11:15:34 -0400

Maybe I am missing the context here, but I thought that there was also a 
valid us case for separating the routing from the prioritization-

Citizen dials 911, and call is routed to PSAP.  PSAP operator then makes a 
call to the local hospital, related to this incident.  This call is 
entitled to the same level of priority as the call to the PSAP, but is not 
routed to the PSAP.

Janet

---

From: [email-masked]
Date: Fri, 21 Mar 2008 22:09:59 -0500

From: Janet P Gunn <[email-masked]>

I believe that there is a case for this, but that the only solution
involves some sort of signing or certification.  In any case I want to
point out that the use case in section 2.6 of
draft-rosenberg-sip-ua-loose-route-02 is not solved by that I-D (or
any other proposal).

Dale