> First of all a question to clarify the requirements further: is it > possible/valid for the request to have no specific priority while its > response does, or should the RPH headers in a response always be the > same or a subset of those in the request (i.e. copied)? I assume the > latter Yes, it should be the latter
> > RFC4412 mostly discusses RPH in the context of endpoints, it states that > proxies MAY ignore it. It does mention the possibility for a proxy to > provide differentiated treatment for "responses containing resource > priority levels", so apparently it was foreseen but omitted from section > 3.1 Yeah, looks like it. Maybe James would comment on this > > Even if RPH is intended to provide certainty of service, then still I > think there are other, IMHO better ways to implement this requirement > without additional standardization. A stateless proxy could send > priority requests out on a different port (or ports, e.g. 1 per level) > than ordinary requests, and treat messages received on the priority > port(s) with the associated priority. There is of course still a risk > for abuse (which can be mitigated, ports could be random or proxy could > encode a magic integrity-protected token). The appropriate Diffserv bits > could be set on each port, and such a scheme enables determining the > priority even before parsing the message. I am sure there are several ways to get the effect of a classic MLPP or ETS system. There was however, a lot of effort put into RPH and as I recall there were quite a few suggestions along the line you propose, but the people working on the problem did not feel they offered a complete solution. Again, my memory is a bit fuzzy on this, and perhaps James could help. One obvious issue is that RPH is standardized, there are implementations here and coming, and changing mechanisms in the absence of evidence that a change is needed may not be wise. We all know about marking the packets. It's highly likely in networks that support DiffServ that the packets will be marked. However, it's real hard to infer the priority of the signaling from the priority of the packets. Some things are impossible (pre-emption as an example). > > If abuse is considered likely and a potential problem, the proxy could > always revert to stateful behavior for priority requests (in combination > with the priority port approach for best effect under high load) Yes, I suppose, but a lot of the networks that will use RPH will have some reasonable ways to police RPH. Those mechanisms probably would work with the response. > > My reasoning is as follows: RPH in responses without additional > mechanisms is not acceptable, as it provides an obvious security hole > (DoS opportunity). So some additional mechanism is required, e.g. > stateful operation to remember the authorised level, or some stateless > mechanism (e.g. as described above). In both cases, the proxy does not > need (and MUST NOT trust) the RPH header in responses to determine the > priority level. So why include it? While policing RPH in the request is somewhat easier than in the response, it's not that much different. I do agree that the security situation is worse enough that it deserves mention in the text, but I don't think the problem is significant enough to warrant discarding the whole idea. Specifically, I don't think you need to outlaw stateless proxies. As an example, an SBC could police RPH at the edge. It may be stateful, it may use some kind of identity mechanism to check authorization... Having policed at the edge, the proxies in the middle may be okay in accepting the RPH. Wouldn't want to put too much trust in that, but it may be sufficient. _______________________________________________ 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
