idnits 2.17.1 draft-roach-sip-herfp-avoidance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 253. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2005) is 6766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG A. B. Roach 3 Internet-Draft R. Sparks 4 Expires: April 19, 2006 B. Campbell 5 Estacado Systems 6 October 16, 2005 8 An Extension to Avoid the Occurance of HERFP 9 draft-roach-sip-herfp-avoidance-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The processing of SIP reqeusts by certain types of proxies can lead 43 to situations in which multiple non-sucessful responses are 44 generated, only one of which is ultimately reported to the originator 45 of the response. In many cases, these non-successful responses 46 indicate conditions that can be addressed by the requestor, and then 47 retried; therefore, the elision of them by proxies can lead to a 48 decrease in the rechability of certain network entites. 50 This document defines a mechanism that can be employed to avoid the 51 dropping of such requests with minimal implementation complexity. 53 Table of Contents 55 1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 3 59 3.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 4 60 3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . . . 7 69 1. Conventions and Definitions 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119. 75 2. Introduction 77 RFC 3261 defines a behavior by which a proxy is allowed, upon receipt 78 of a request, to retarget it to multiple destinations (serially, in 79 parallel, or a combination of the two). This behavior is referred to 80 as "forking." If a proxy forks a request, it generally waits until 81 one of the multiple requests succeeds (with a 200-class response), or 82 until they all fail. Upon failure, only one error response -- the 83 one deemed "best" by the proxy -- is returned towards the UAC that 84 initiated the request. As a consequence, such forking can result in 85 a significant loss of information about the User Agent Servers that 86 were contacted. This behavior leads to a whole class of problems, 87 historically referred to as Heterogeneous Error Response Forking 88 Problems (HERFPs). These problems include the inablity to perform 89 HTTP-style authentication through forking proxies, difficulty in 90 negotiating many extensions, and forcing proxies to recurse on 300- 91 class responses (thus taking control of such retargeting out of the 92 hands of the users). 94 Several key architects of the SIP protocol have been working on this 95 problem for nearly five years. Even the most promising of such 96 solutions (draft-mahy-sipping-herfp-fix-00) result in a significant 97 increase in implementation complexity at proxies, and require 98 gyrations at the UAC to deal with relatively intimate knowledge of 99 "failed" branches of forked requests. 101 As a consequence of the stubborness of this class of problem and the 102 resultant complexity of any proposed solutions, the authors of this 103 document have concluded that HERFPs may be incurable, and should 104 instead be avoided. This document describes prophylactic measures by 105 which networks can prevent HERFPs altogether, instead of trying to 106 solve the symptoms that arise after such problems have already 107 occured. 109 3. Mechanism 111 3.1. User Agent Client Behavior 113 User Agent Clients that wish to require that the behavior exhibited 114 in this document can indicate such a requirement by including a 115 "Proxy-Require" header field containing a token of "rmt". ("rmt" is 116 an abbreviation for "Redirect Multiple Targets"). 118 In general, however, proxies implementing the mechanism described in 119 this document are expected to apply it in all cases; the inclusion of 120 such a "Proxy-Require" header field is useful only if the UAC wishes 121 for requests through non-compliant proxies to actually fail. 123 User Agent Clients are generally required to handle 300-class 124 responses with multiple "Contact" header fields in an intelligent 125 manner, typically taking q-values into consideration. The mechanism 126 described in this document does nothing to change this fact; however, 127 it does emphasize the importance of such handling. 129 As with proxies, one common ordering mechanism for clients is to use 130 the qvalue parameter of targets obtained from Contact header fields. 131 Targets are processed from highest qvalue to lowest. Targets with 132 equal qvalues may be processed in parallel. Additionally, the 133 ordering mechanism may interact with the user to determine a 134 preferred behavior, providing finer-grained control over calls than 135 is possible with proxy recursion. 137 Note that this specification places no normative requirements on User 138 Agent Clients. 140 3.2. User Agent Server Behavior 142 No modification to the behavior of User Agent Servers is necessary 143 for this mechanism. 145 3.3. Proxy Behavior 147 Proxies compliant to this specification have two simple requirements 148 placed upon them: 150 o Proxies MUST NOT recurse on 300-class responses. 151 o Proxies MUST NOT fork requests of any kind. 153 The first requirement can be met by trivially proxying all 300-class 154 responses back towards the UAC instead of acting upon them. 156 One trivial way to meet the second requirement is as follows: proxies 157 form the target set as they normally do. If the target set contains 158 more than one target, the proxy responds to the request with a 300 159 response instead of proxying it. This response contains a Contact 160 header-field containing every target in the target set. Handling in 161 the case of target sets with zero or one targets remains unchanged. 163 The only additional normative behavior described for proxies 164 compliant to this specification is that such proxies are not required 165 to return a 420 response as a consequence of encountering a "Proxy- 166 Require" header field containing a token of "rmt". 168 4. Security Considerations 170 One salient difference between a proxy forking a request and 171 returning a 300-class response to the requestor is that responding 172 with a 300-class response provides the requestor with a full list of 173 targets, whereas forking the request reveals only the contact 174 information for the successful respondant. While providing this full 175 list of contacts is not likely to reveal private information (since 176 some subset of them will be revealed when the request completes), it 177 is possible that some parties may imagine a requirement for hiding 178 the full set of targets. If such is the case, this requirement can 179 be satisfied without requiring any additional protocol modification: 180 instead of returning the target set to the requestor, the server 181 instead creates a set of unique tokens -- one for each target -- and 182 uses them to create new URIs. The host portion of these URIs will 183 resolve to the server itself. When a request arrives for any of 184 these tokens, the server rewrites the URI to be the appropriate 185 target and proxies the request normally. This technique can be 186 performed either statefully (the token is simply a correlator), or 187 statelessly (the token is an encrypted form of the target URI, 188 possibly with an embedded timestamp to limit validity). 190 5. IANA Considerations 192 [TODO: Add "rmt" Proxy-Require tag] 194 6. References 196 6.1. Normative References 198 6.2. Informative References 199 Authors' Addresses 201 Adam Roach 202 Estacado Systems 203 17210 Campbell Rd. 204 Suite 250 205 Dallas, TX 75252 206 US 208 Phone: sip:adam@estacado.net 209 Email: adam@estacado.net 211 Robert Sparks 212 Estacado Systems 213 17210 Campbell Rd. 214 Suite 250 215 Dallas, TX 75252 216 US 218 Phone: sip:RjS@estacado.net 219 Email: RjS@estacado.net 221 Ben Campbell 222 Estacado Systems 223 17210 Campbell Rd. 224 Suite 250 225 Dallas, TX 75252 226 US 228 Phone: sip:ben@estacado.net 229 Email: ben@estacado.net 231 Intellectual Property Statement 233 The IETF takes no position regarding the validity or scope of any 234 Intellectual Property Rights or other rights that might be claimed to 235 pertain to the implementation or use of the technology described in 236 this document or the extent to which any license under such rights 237 might or might not be available; nor does it represent that it has 238 made any independent effort to identify any such rights. Information 239 on the procedures with respect to rights in RFC documents can be 240 found in BCP 78 and BCP 79. 242 Copies of IPR disclosures made to the IETF Secretariat and any 243 assurances of licenses to be made available, or the result of an 244 attempt made to obtain a general license or permission for the use of 245 such proprietary rights by implementers or users of this 246 specification can be obtained from the IETF on-line IPR repository at 247 http://www.ietf.org/ipr. 249 The IETF invites any interested party to bring to its attention any 250 copyrights, patents or patent applications, or other proprietary 251 rights that may cover technology that may be required to implement 252 this standard. Please address the information to the IETF at 253 ietf-ipr@ietf.org. 255 Disclaimer of Validity 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 260 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 261 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 262 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Copyright Statement 267 Copyright (C) The Internet Society (2005). This document is subject 268 to the rights, licenses and restrictions contained in BCP 78, and 269 except as set forth therein, the authors retain all their rights. 271 Acknowledgment 273 Funding for the RFC Editor function is currently provided by the 274 Internet Society.