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