[Sip] The emergency services routing use case

[Dale.Worley at comcast.net]

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:psap at 10.1.1.1 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:psap at 10.1.1.1;lr>

    INVITE sip:psap at 10.1.1.1 SIP/2.0
    From: xxx
    To: xxx
    Target: urn:service:sos

    INVITE sip:psap at 10.1.1.1 SIP/2.0
    From: xxx
    To: xxx
    History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
	    <sip:psap at 10.1.1.1>;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:Dale.Worley at example.com;lr>

    INVITE sip:Dale.Worley at example.com SIP/2.0
    From: xxx
    To: xxx
    Target: urn:service:sos

    INVITE sip:Dale.Worley at example.com SIP/2.0
    From: xxx
    To: xxx
    History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
	    <sip:Dale.Worley at example.com>;index=2

By hypothesis, all of these requests are intended to be routed to
sip:Dale.Worley at example.com 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip