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, [EMAIL PROTECTED] 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:[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
_______________________________________________
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
