draft-gunn-sip-req-for-rph-in-responses-00: What is impact on response?

I'm still struggling with the rph-in-response question. I
was hoping  
to get some insight from
draft-gunn-sip-req-for-rph-in-responses-00,  
but I'm still left unclear on a few points.

For the record, this draft adds supporting rationale for
draft-polk- 
sip-rph-in-responses-00.txt.

I understand from this draft that a node making a call that
would  
need RPH information might not know what RPH value would
apply at the  
time the call is launched by sending INVITE. This is because
the  
priority granted will depend on external factors, including 

potentially the priority status of the call target. So we
need a way  
to inform the network elements along the path (including the
UAC) as  
to what priority they should grant the call.

Now for the questions:

1) RFC 4412 (which defines RPH) is not clear to me on the  
relationship between priorities, requests, responses, and
dialogs.  
Specifically, does an RPH value expressed in an INVITE
transaction  
apply to a dialog, or does it apply only to the request in
which it  
appears? This has implications for what happens should an
RPH value  
change mid-dialog, which is what the rph-responses work is
proposing.  
The only way I can see that this works is for RPH values to
apply  
only to the request (or perhaps request or response) in
which they  
occur. Supporting UAs would then have to remember the RPH
value and  
include it in all further requests (and perhaps responses).
If the  
RPH value is not resent, then the RPH value would cease to
apply. Now  
here's the problem: The RPH value seems to impact the
processing of  
the SIP messages themselves, and the priority of the media
flow  
established in a dialog. So what happens to the priority of
a media  
flow when subsequent transactions within the dialog
experience  
changes in RPH values?

2) What is the impact of RPH in a response? Does this value
get  
interpreted and used to prioritize the response (which has
some  
substantial implications for overload processing) or is it
simply  
informative, such that the UAC learns the RPH value and can
include  
it in future requests? Otherwise worded, are we suggesting
that the  
responses to requests be treated with different
prioritization than  
the request itself?

3) What is the authentication/authorization model? This has
two sub- 
problems.

3A) First, we cannot (in SIP) challenge a response. There
are no  
"responses to responses" -- they can either be
transmitted or  
dropped.  In some cases, responses can be modified by
proxies. This  
lead us to the model of connected-identity we currently
have, where  
identity is asserted by sending a request in the opposing
direction  
of flow. So, let's say a UAS receiving a low-priority
request sends a  
high-priority response. What information in this response is
used by  
the proxy layer to decide whether or not the UAS is
authorized to  
assert this level of priority? It can't be
"identity" (because in the  
absence of an outbound-style last-hop persistent TLS
connection, we  
can only do assert identity on requests). What happens if a
UAS  
asserts an RPH value it is not authorized to use? Do the
proxies  
simply mark it back down, or does the request get dropped?
And how  
can any of this work in a stateless element?

3B) Assume the original UAC learns in a response from the
UAS of a  
new RPH value, and then uses it in future requests within
the dialog.  
How does the proxy layer decide the UAS is authorized to use
this new  
RPH? The UAS's identity hasn't changed, and that identity
was not  
originally authorized for the higher RPH level. There was no
crypto- 
token in the response that can be evaluated. Dialog-stateful
proxies  
that saw the response might be able to track this as
authorization to  
the UAC, but stateless proxies will have no clue.

As a consequence of the two aspects of problem 3, all a
stateless  
proxy can do is either ignore RPH entirely or blindly assume
that the  
RPH value in a request is valid and act on it to the best of
its  
ability. This raises some very interesting security
questions in an  
environment that is rich with stateless proxies.

I think for this to really work, we need to make a couple of

enhancements.

First, we need to understand whether the RPH value of a
request  
applies to any response to that request -- that is, whether
the  
applied value cannot change between request and response. I
think  
that the response priority is the same as the request
priority, as  
doing otherwise either requires changing the fundamental  
authentication model of SIP, or it requires stateful proxies
combined  
with draft-ietf-sip-outbound and thereby making this
extension so  
narrow as to arguably be in the "P-header"
domain.

Second, we need to understand that RPH can change with each
new  
request, whether in a dialog or not, and we'll need to
clarify the  
interaction between the changing of RPH within a dialog and
the  
priority of any media session associated with that dialog.

Thirdly, we need some way for the UAC to be granted the
right to use  
an RPH by a response. This could either be some sort of
token sent by  
the UAS to the UAC, or it could be a requirement that the
admitting  
proxy (the one to which the UAC directly connects) be dialog
stateful.

---
Dean, the priority-confused.

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

draft-gunn-sip-req-for-rph-in-responses-00: What is impact on response?

Thread: draft-gunn-sip-req-for-rph-in-responses-00: What is impact on response?