[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] The emergency services routing use case
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
At 09:30 PM 3/19/2008, Dale.Worley at comcast.net wrote:
>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
_______________________________________________
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