An Extension to Avoid the Occurance of HERFP

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RFC 3261 defines a behavior by which a proxy is allowed, upon receipt of a request, to retarget it to multiple destinations (serially, in parallel, or a combination of the two). This behavior is referred to as "forking." If a proxy forks a request, it generally waits until one of the multiple requests succeeds (with a 200-class response), or until they all fail. Upon failure, only one error response -- the one deemed "best" by the proxy -- is returned towards the UAC that initiated the request. As a consequence, such forking can result in a significant loss of information about the User Agent Servers that were contacted. This behavior leads to a whole class of problems, historically referred to as Heterogeneous Error Response Forking Problems (HERFPs). These problems include the inablity to perform HTTP-style authentication through forking proxies, difficulty in negotiating many extensions, and forcing proxies to recurse on 300-class responses (thus taking control of such retargeting out of the hands of the users). Several key architects of the SIP protocol have been working on this problem for nearly five years. Even the most promising of such solutions (draft-mahy-sipping-herfp-fix-00) result in a significant increase in implementation complexity at proxies, and require gyrations at the UAC to deal with relatively intimate knowledge of "failed" branches of forked requests. As a consequence of the stubborness of this class of problem and the resultant complexity of any proposed solutions, the authors of this document have concluded that HERFPs may be incurable, and should instead be avoided. This document describes prophylactic measures by which networks can prevent HERFPs altogether, instead of trying to solve the symptoms that arise after such problems have already occured.

User Agent Clients that wish to require that the behavior exhibited in this document can indicate such a requirement by including a "Proxy-Require" header field containing a token of "rmt". ("rmt" is an abbreviation for "Redirect Multiple Targets"). In general, however, proxies implementing the mechanism described in this document are expected to apply it in all cases; the inclusion of such a "Proxy-Require" header field is useful only if the UAC wishes for requests through non-compliant proxies to actually fail. User Agent Clients are generally required to handle 300-class responses with multiple "Contact" header fields in an intelligent manner, typically taking q-values into consideration. The mechanism described in this document does nothing to change this fact; however, it does emphasize the importance of such handling. As with proxies, one common ordering mechanism for clients is to use the qvalue parameter of targets obtained from Contact header fields. Targets are processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel. Additionally, the ordering mechanism may interact with the user to determine a preferred behavior, providing finer-grained control over calls than is possible with proxy recursion. Note that this specification places no normative requirements on User Agent Clients.

No modification to the behavior of User Agent Servers is necessary for this mechanism.

Proxies compliant to this specification have two simple requirements placed upon them: Proxies MUST NOT recurse on 300-class responses. Proxies MUST NOT fork requests of any kind. The first requirement can be met by trivially proxying all 300-class responses back towards the UAC instead of acting upon them. One trivial way to meet the second requirement is as follows: proxies form the target set as they normally do. If the target set contains more than one target, the proxy responds to the request with a 300 response instead of proxying it. This response contains a Contact header-field containing every target in the target set. Handling in the case of target sets with zero or one targets remains unchanged. The only additional normative behavior described for proxies compliant to this specification is that such proxies are not required to return a 420 response as a consequence of encountering a "Proxy-Require" header field containing a token of "rmt".

One salient difference between a proxy forking a request and returning a 300-class response to the requestor is that responding with a 300-class response provides the requestor with a full list of targets, whereas forking the request reveals only the contact information for the successful respondant. While providing this full list of contacts is not likely to reveal private information (since some subset of them will be revealed when the request completes), it is possible that some parties may imagine a requirement for hiding the full set of targets. If such is the case, this requirement can be satisfied without requiring any additional protocol modification: instead of returning the target set to the requestor, the server instead creates a set of unique tokens -- one for each target -- and uses them to create new URIs. The host portion of these URIs will resolve to the server itself. When a request arrives for any of these tokens, the server rewrites the URI to be the appropriate target and proxies the request normally. This technique can be performed either statefully (the token is simply a correlator), or statelessly (the token is an encrypted form of the target URI, possibly with an embedded timestamp to limit validity).

[TODO: Add "rmt" Proxy-Require tag]