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 PROTECTED] 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 PROTECTED];lr>
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: xxx
To: xxx
Target: urn:service:sos
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: xxx
To: xxx
History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
<sip:[EMAIL PROTECTED]>;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 PROTECTED];lr>
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: xxx
To: xxx
Target: urn:service:sos
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: xxx
To: xxx
History-Info: <urn:service:sos?Reason=SIP%3Bcause%3D302>;index=1,
<sip:[EMAIL PROTECTED]>;index=2
By hypothesis, all of these requests are intended to be routed to
sip:[EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
