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

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 14:14:24 -0600

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 15:22:35 -0600

I'll answer part of your long questionnaire  ;-)

>relationship between priorities, requests, responses, and dialogs.

RFC 4412 explicitly creates a priority for requests and dialogs 
within UAs and Proxies that allow a priority to be assigned within a 
namespace.  I agree it isn't so clear about responses; though it has 
text stated proxies should be wary of changing priorities within a 
response by "colluding UAs."

In stateful proxies, responses were supposed to be afforded the same 
priority as their request partner message within a transaction.  This 
is to give all messages within a transaction a priority for special 
handling in processing queues, and rejections if a proxy knew a lower 
priority request wouldn't get through to the destination (perhaps 
because it knew the UAS was already engaged in a higher priority dialog).

RFC 4412 was not clear what to do with responses in stateless 
proxies. This is what draft-polk- sip-rph-in-responses-00 currently addresses.

>appears?

see above (it applies to everything (requests and dialogs) except for 
in responses in stateless proxies)

>This has implications for what happens should an RPH value
>change mid-dialog,

obviously the transaction occurs before dialog changes, so the dialog 
would maintain the priority it currently has until successful 
acceptance of the new transaction about the dialog changes the 
priority of the dialog.

>which is what the rph-responses work is proposing.

...which draft-polk- sip-rph-in-responses-00 currently is not yet

>occur.

see my reply, and I think this works everywhere the namespace is 
accepted.  In other words, RPH applies to a transaction involving 
stateful proxies until the dialog starts, which takes on that 
priority within the dialog. If a new transaction occurs within that 
Call-ID, the new priority affects that transaction until it is 
successful, then the dialog takes on that new priority.

>Supporting UAs would then have to remember the RPH value

of course they would, per dialog

>and
>include it in all further requests (and perhaps responses).

yes, unless the request includes a change in priorities within an 
acceptable namespace

>If the
>RPH value is not resent, then the RPH value would cease to apply.

This isn't stated, but I think once a priority is established within 
a dialog, it doesn't cease because a new transaction within that 
dialog didn't contain the same namespace.priority-value.  But I do 
expect any new transaction to contain at least the same RPH values as 
the existing dialog.

>Now
>established in a dialog.

This isn't a problem, since this is the intent

>So what happens to the priority of a media flow when subsequent 
>transactions within the dialog experience changes in RPH values?

The priority of the media flow changes to match that of the new 
transaction within the established dialog.

If the media established a priority in the first place, it shouldn't 
be hard to change the priority mid-stream, should it?

If this changes the DSCP value, then there needs to be a mechanism to 
change the DSCP.  I didn't rev this ID for this meeting, but I will 
very soon (taking out all mention of servers from the ID to satisfy 
resistance I got within the MMUSIC WG in Chicago)
http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-01.txt

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 16:10:53 -0600

On Nov 21, 2007, at 3:22 PM, James M. Polk wrote:
> This isn't stated, but I think once a priority is established  
> within a dialog, it doesn't cease because a new transaction within  
> that dialog didn't contain the same namespace.priority-value.  But  
> I do expect any new transaction to contain at least the same RPH  
> values as the existing dialog.

If RPH can change on a per-message cycle within a dialog, is the  
transmission of a message without an RPH header within the dialog the  
same as explicitly sending an RPH that conveys no priority? This  
needs to be clear in the documentation.

--
dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 22 Nov 2007 12:40:15 +0100

If this is an issue, I think it is an issue within the existing RFC in
regard to requests themselves:

RFC 4412 section 3.1.

   There is no protocol requirement that all requests within a SIP
   dialog or session use the 'Resource-Priority' header field.  Local
   administrative policy MAY mandate the inclusion of the
   'Resource-Priority' header field in all requests.  Implementations of
   this specification MUST allow inclusion to be either by explicit user
   request or automatic for all requests.

Additionally I could find no requirement that specified that the value
used in an INVITE request had to be the same as a value used in say, a
reINVITE request in the same dialog, even when the Resource-Priority
header was included in both requests.

I think this leads to the need of this discussion to clearly identify in
the questions raised:

-	whether the point concerns the enhancement to RFC 4412 to
support some new use cases;
-	whether there is a problem in the existing RFC 4412 itself, i.e.
the existing documentation is broken.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 10:11 PM
> To: James M. Polk
> Cc: IETF SIP List
> Subject: Re: [Sip] 
> draft-gunn-sip-req-for-rph-in-responses-00: What is impacton response?
> 
> 
> > This isn't stated, but I think once a priority is 
> established within a 
> > dialog, it doesn't cease because a new transaction within 
> that dialog 
> > didn't contain the same namespace.priority-value.  But I do 
> expect any 
> > new transaction to contain at least the same RPH values as the 
> > existing dialog.
> 
> If RPH can change on a per-message cycle within a dialog, is 
> the transmission of a message without an RPH header within 
> the dialog the same as explicitly sending an RPH that conveys 
> no priority? This needs to be clear in the documentation.
> 
> --
> dean
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip