Subject: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Oct 2006 01:06:54 -0500

ECRIT WG

I've written a new ID to create a SIP Resource-Priority header namespace to 
be used during emergency calling.  Right now, I am calling this namespace 
"Fred&Barney" to get folks attention, but the ID calls out several 
alternatives to replace this otherwise excellent namespace string.

The URL for this ID is here:

http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-00.txt

Brian and I have talked for more than 2 years about doing this, and with a 
few minutes of spare time before the -00 deadline, I thought I'd start the 
ball rolling by calling out several alternative strings to use as the 
namespace, and some early rules around its usage - as one never knows how 
long it will take to get an RPH namespace to RFC status.... (sigh)

I have the number of relative priority levels at 5 at the moment, because I 
believe (but can be talked out of) this namespace being used not only for 
public caller-to-PSAP, but also PSAP-to-PSAP and PSAP-to-first_responder 
(individual or dispatcher).  This may be differentiated with different 
priority levels rather than different namespaces (thus creating at least 3 
for ~ each country jurisdiction).  I think if we can get this into one 
namespace, it scales better and interoperates better.

(i.e we don't want too many namespaces because RFC 4412 states unknown 
namespaces mean the header is ignored or errored - which might also be an 
undesireable event)

Comments are appreciated

Thanks
James

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Oct 2006 09:06:52 -0400

Rather than focusing on labels and names, or how many there should  
be, there is a much more fundamental question, namely whether this is  
needed at all. I'm concerned that the approach as proposed is  
potentially a security risk and has a semantics problem.

For citizen-to-authority calls, calls must already be recognizable  
and routed towards the PSAP. Thus, proxies that recognize such calls  
can provide them with appropriate signaling treatment, including but  
not limited to priority, based on that information.  (Otherwise,  
attackers would simply label every call to their friends as having  
this priority, given that we can't require authentication for  
emergency calls.)

For authority-to-authority calls, it seems that there is significant  
overlap with the ETS namespace.

Even ignoring these issues, I'm unconvinced that packing these  
unrelated calls into one ordered namespace makes sense. After all,  
there is no inherent reason why authority-to-civilian calls, say,  
should have higher (or lower) priority than the converse. Namespaces  
need to have a consistent priority order across jurisdictions to be  
meaningful; you can't have "priority 5" be more urgent than "priority  
4" in one jurisdiction and the opposite in another.

Henning

On Oct 27, 2006, at 2:06 AM, James M. Polk wrote:

> ECRIT WG
>
> I've written a new ID to create a SIP Resource-Priority header  
> namespace to be used during emergency calling.  Right now, I am  
> calling this namespace "Fred&Barney" to get folks attention, but  
> the ID calls out several alternatives to replace this otherwise  
> excellent namespace string.
>
> Brian and I have talked for more than 2 years about doing this, and  
> with a few minutes of spare time before the -00 deadline, I thought  
> I'd start the ball rolling by calling out several alternative  
> strings to use as the namespace, and some early rules around its  
> usage - as one never knows how long it will take to get an RPH  
> namespace to RFC status.... (sigh)
>
> I have the number of relative priority levels at 5 at the moment,  
> because I believe (but can be talked out of) this namespace being  
> used not only for public caller-to-PSAP, but also PSAP-to-PSAP and  
> PSAP-to-first_responder (individual or dispatcher).  This may be  
> differentiated with different priority levels rather than different  
> namespaces (thus creating at least 3 for ~ each country  
> jurisdiction).  I think if we can get this into one namespace, it  
> scales better and interoperates better.
>
> (i.e we don't want too many namespaces because RFC 4412 states  
> unknown namespaces mean the header is ignored or errored - which  
> might also be an undesireable event)
>
> Comments are appreciated
>
> Thanks
> James
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 09:28:50 -0400

I think there is value to the namespace.

For one thing, it does exactly what we want: specify a resource priority for
a call.  While the marking method tells a proxy that the call is a 9-1-1
call, it's not clear that we should be using what is in a Route Header to
affect the resource priority of that call.

I think the authority to authority use is a little less compelling.  I think
those calls will use a MLLP like priority/preemption scheme, and I don't
know why the existing RPH namespaces aren't good enough.

However, there is the call back (authority to citizen).  In many cases, it
is appropriate to have some resource priority for those calls.

I do share some of Henning's concerns about whether ordered priority has any
place in this namespace.  I'm not sure that it does, but I want to think
about that.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 9:07 AM
> To: James M. Polk
> Cc: [email-masked]'
> Subject: Re: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Oct 2006 10:48:41 -0400

> affect the resource priority of that call.

Just so that we don't talk past each other: We wouldn't be using Route 
to indicate an emergency call; that's indicated by the request URI 
and/or To header.

If all citizen-to-authority emergency calls should get priority, we're 
essentially saying the same thing twice, which means we now have to 
decide what happens for calls that

- only indicate that this is an emergency call
- only indicate some kind of RP
- do both, but use the "wrong" RP value (e.g., use the 
authority-authority code)

Three new cases, no net gain.

Also, you haven't addressed my main concern, namely that a RP indication 
without a strong tie to PSAP routing is a rather large security hole.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 11:33:23 -0400

> to indicate an emergency call; that's indicated by the request URI
Well, there is Jonathan's proposal, but even if there wasn't, I thought the
service URN has to go in Route because after LoST mapping it wouldn't be in
Request URI.

Take the case of the proxy doing dialstring interpretation, and just for
fun, make it not the one that does LoST.

UA:
INVITE sip:911;phone-context=[email-masked];user=dialstring
To: sip:911;phone-context=[email-masked];user=dialstring

First Proxy
INVITE sip:urn:service:sos
To: sip:911;phone-context=[email-masked];user=dialstring

Second Proxy
INVITE sip:[email-masked]
To: sip:911;phone-context=[email-masked];user=dialstring

No service URN.  I had thought the messages were:
First Proxy
INVITE sip:urn:service:sos
To: sip:911;phone-context=[email-masked];user=dialstring
Route: sip:urn:service:sos;lr

Second Proxy
INVITE sip:[email-masked]
To: sip:911;phone-context=[email-masked];user=dialstring
Route: sip:urn:service:sos;lr

> Three new cases, no net gain.
I would say that the presence of a service URN is not a request for resource
priority, but is only used for route determination. 

As I said, I'm not sure there is a need for an ordered priority in this
namespace, but if there is, the same problems you would have with use of RPH
in any circumstances apply.   No new problems

> without a strong tie to PSAP routing is a rather large security hole.
RPH in general has that issue. 

Of course, the same is true of using the service URN.  Ignoring for a
moment, my argument above:

UA:
INVITE sip:[email-masked]
To: sip:urn:service:sos

Is exactly the problem you are describing, right?  What defenses do we have
against this?  I think the only thing you could do is to verify that for the
location in the Geolocation header, the RequestURI was the LoST response.

Brian