SIP WG A. B. Roach Internet-Draft R. Sparks Expires: April 19, 2006 B. Campbell Estacado Systems October 16, 2005 An Extension to Avoid the Occurance of HERFP draft-roach-sip-herfp-avoidance-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The processing of SIP reqeusts by certain types of proxies can lead to situations in which multiple non-sucessful responses are generated, only one of which is ultimately reported to the originator of the response. In many cases, these non-successful responses indicate conditions that can be addressed by the requestor, and then retried; therefore, the elision of them by proxies can lead to a decrease in the rechability of certain network entites. Roach, et al. Expires April 19, 2006 [Page 1] Internet-Draft MSRP Relays October 2005 This document defines a mechanism that can be employed to avoid the dropping of such requests with minimal implementation complexity. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 3 3.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 4 3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Roach, et al. Expires April 19, 2006 [Page 2] Internet-Draft MSRP Relays October 2005 1. Conventions and Definitions 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. 2. Introduction 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. 3. Mechanism 3.1. User Agent Client Behavior User Agent Clients that wish to require that the behavior exhibited in this document can indicate such a requirement by including a Roach, et al. Expires April 19, 2006 [Page 3] Internet-Draft MSRP Relays October 2005 "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. 3.2. User Agent Server Behavior No modification to the behavior of User Agent Servers is necessary for this mechanism. 3.3. Proxy Behavior Proxies compliant to this specification have two simple requirements placed upon them: o Proxies MUST NOT recurse on 300-class responses. o 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. Roach, et al. Expires April 19, 2006 [Page 4] Internet-Draft MSRP Relays October 2005 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". 4. Security Considerations 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). 5. IANA Considerations [TODO: Add "rmt" Proxy-Require tag] 6. References 6.1. Normative References 6.2. Informative References Roach, et al. Expires April 19, 2006 [Page 5] Internet-Draft MSRP Relays October 2005 Authors' Addresses Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Phone: sip:adam@estacado.net Email: adam@estacado.net Robert Sparks Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Phone: sip:RjS@estacado.net Email: RjS@estacado.net Ben Campbell Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Phone: sip:ben@estacado.net Email: ben@estacado.net Roach, et al. Expires April 19, 2006 [Page 6] Internet-Draft MSRP Relays October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Roach, et al. Expires April 19, 2006 [Page 7]