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

[Dean Willis <[e-mail]>]

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://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip