idnits 2.17.1 draft-sparks-sip-nit-actions-03.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 194: '... A SIP element MUST NOT send any pro...' RFC 2119 keyword, line 197: '... A SIP element MUST NOT respond to a...' RFC 2119 keyword, line 202: '... A SIP element MAY respond to a non-...' RFC 2119 keyword, line 205: '...sport, a SIP element MUST respond to a...' RFC 2119 keyword, line 212: '...eful SIP element MUST NOT send a respo...' (1 more instance...) 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 (Jan 2005) is 7039 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational draft: draft-sparks-sip-nit-problems (ref. '3') Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Sparks 2 Internet-Draft Xten 3 Expires: July 2, 2005 Jan 2005 5 Actions addressing identified issues with the Session Initiation 6 Protocol's non-INVITE Transaction 7 draft-sparks-sip-nit-actions-03 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 July 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This draft describes modifications to the Session Initiation Protocol 43 (SIP) to address problems that have been identified with the SIP 44 non-INVITE transaction. These modifications reduce the probability 45 of messages losing the race condition inherent in the non-INVITE 46 transaction and reduce useless network traffic. They also improve 47 the robustness of SIP networks when elements stop responding. These 48 changes update behavior defined in RFCs 3261. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Improving the situation when responses are only delayed . . . 3 54 2.1 Action 1: Make the best use of provisional responses . . . 3 55 2.2 Action 2: Remove the useless late-response storm . . . . . 4 56 3. Improving the situation when an element is not going to 57 respond . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Normative Updates to RFC 3261 . . . . . . . . . . . . . . . . 5 59 4.1 Action 1 . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2 Action 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . 8 68 1. Introduction 70 There are a number of unpleasant edge conditions created by the SIP 71 non-INVITE transaction (NIT) model's fixed duration. The negative 72 aspects of some of these are exacerbated by the effect provisional 73 responses have on the non-INVITE transaction state machines. These 74 problems are documented in [3]. In summary: 76 A non-INVITE transaction must complete immediately or risk losing 77 a race 79 Losing the race will cause the requester to stop sending traffic 80 to the responder (the responder will be temporarily blacklisted) 82 Provisional responses can delay recovery from lost final responses 84 The 408 response is useless for the non-INVITE transaction 86 As non-INVITE transactions through N proxies time-out, there can 87 be an O(N^2) storm of the useless 408 responses 89 This draft specifies updates to RFC 3261 [1] to improve the behavior 90 of SIP elements when these edge conditions arise. 92 2. Improving the situation when responses are only delayed 94 There are two goals to achieve when we constrain the problem to those 95 cases where all elements are ultimately responsive and networks 96 ultimately deliver messages: 98 o Reduce the probability of losing the race, preferably to the point 99 that it is negligible 101 o Reduce or eliminate useless messaging 103 2.1 Action 1: Make the best use of provisional responses 105 o Disallow non-100 provisionals to non-INVITE requests 107 o Disallow 100 Trying to non-INVITE requests before Timer E reaches 108 T2 (for UDP hops) 110 o Allow 100 Trying after Timer E reaches T2 (for UDP hops) 112 o Allow 100 Trying for hops over reliable transports 114 Since non-INVITE transactions must complete rapidly ([3]), any 115 information beyond "I'm here" (which can be provided by a 100 Trying) 116 can be just as usefully delayed to the final response. Sending 117 non-100 provisionals wastes bandwidth. 119 As shown in [3], sending any provisional response inside a NIT before 120 Timer E reaches T2 damages recovery from failure of an unreliable 121 transport. 123 Without a provisional, a late final response is the same as no 124 response at all and will likely result in blacklisting the late 125 responding element ([3]). If an element is delaying its final 126 response at all, sending a 100 Trying after Timer E reaches T2 127 prevents this blacklisting without damaging recovery from unreliable 128 transport failure. 130 Blacklisting on a late response occurs even over reliable transports. 131 Thus, if an element processing a request received over a reliable 132 transport is delaying its final response at all, sending a 100 Trying 133 well in advance of the timeout will prevent blacklisting. Sending a 134 100 Trying immediately will not harm the transaction as it would over 135 UDP, but a policy of always sending such a message results in 136 unneccessary traffic. A policy of sending a 100 Trying after the 137 period of time in which Timer E reaches T2 had this been a UDP hop is 138 one reasonable compromise. 140 2.2 Action 2: Remove the useless late-response storm 142 o Disallow 408 to non-INVITE requests 144 o Absorb stray non-INVITE responses at proxies 146 A 408 to non-INVITE will always arrive too late to be useful ([3]), 147 The client already has full knowledge of the timeout. The only 148 information this message would convey is whether or not the server 149 believed the transaction timed out. However, with the current design 150 of the NIT, a client can't do anything with this knowledge. Thus the 151 408 simply wasting network resources and contributes to the response 152 bombardment illustrated in [3]. 154 Late non-INVITE responses by definition arrive after the client 155 transaction's Timer F has fired and the client transaction has 156 entered the Terminated state. Thus, these responses cannot be 157 distinguished from strays. Changing the protocol behavior to 158 prohibit forwarding non-INVITE stray responses stops the late 159 response storm. It also improves the proxy's defenses against 160 malicious users counting on the RFC 3261 requirement to forward such 161 strays. 163 3. Improving the situation when an element is not going to respond 165 When we expand the scope of the problem to also deal with element or 166 network failure, we have more goals to achieve: 168 o Identifying when an element is non-responsive 170 o Minimizing or eliminating falsely identifying responsive elements 171 as non-responsive 173 o Avoiding non-responsive elements with future requests 175 Action 1 helps with the first two goals, dramatically improving an 176 element's ability to distinguish between failure and delayed response 177 from the next downstream element. Some response, either provisional 178 or final, will almost certainly be received before the transaction 179 times out. So, an element can more safely assume that no response at 180 all indicates the peer is not available and follow the existing 181 requirements in [1] and [2] for that case. 183 Achieving the third goal requires more agressive changes to the 184 protocol. As noted in [3], future non-invite transactions are likely 185 to fail again unless the implementation takes steps beyond what is 186 defined in [1] and [2] to remember non-responsive destinations 187 between transactions. Standardizing these extra steps is left to 188 future work. 190 4. Normative Updates to RFC 3261 192 4.1 Action 1 194 A SIP element MUST NOT send any provisional response with a 195 Status-Code other than 100 to a non-INVITE request. 197 A SIP element MUST NOT respond to a non-INVITE request with a 198 Status-Code of 100 over any unreliable transport, such as UDP, before 199 the amount of time it takes a client transaction's Timer E to be 200 reset to T2. 202 A SIP element MAY respond to a non-INVITE request with a Status-Code 203 of 100 over a reliable transport at any time. 205 Without regard to transport, a SIP element MUST respond to a 206 non-INVITE request with a Status-Code of 100 if it has not otherwise 207 responed after the amount of time it takes a client transaction's 208 Timer E to be reset to T2. 210 4.2 Action 2 212 A transaction-stateful SIP element MUST NOT send a response with 213 Status-Code of 408 to a non-INVITE request. As a consequence, an 214 element that can not respond before the transaction expires will not 215 send a final response at all. 217 A transaction-stateful SIP proxy MUST NOT send any response to a 218 non-INVITE request unless it has a matching server transaction that 219 is not in the Terminated state. As a consequence, this proxy will 220 not forward any "late" non-INVITE response. 222 5. Security Considerations 224 This document makes a number of small changes to the core SIP 225 specification [1] to improve the robustness of SIP non-INVITE 226 transactions. Many of these actions also prevent flooding and 227 denial-of-service attacks. 229 One change prohibits proxies and User Agents from sending 408 230 responses to non-INVITE transactions. Without this change, proxies 231 automatically generate a storm of useless responses as described in 232 [3]. An attacker could capitalize on this by enticing User Agents to 233 send non-INVITE requests to a black hole (through social engineering 234 or DNS poisoning) or by selectively dropping responses. 236 Another change prohibits proxies from forwarding late responses. 237 Without this change, an attacker could easily forge messages which 238 appear to be late responses. All proxies compliant with RFC 3261 are 239 required to forward these responses, wasting bandwidth and CPU and 240 potentially overwhelming target User Agents (especially those with 241 low speed connections). 243 The remainder of these changes do not affect the security of the SIP 244 protocol. 246 6. IANA Considerations 248 This document requires no action by IANA. 250 7. Contributors 252 Rohan Mahy provided the Security Considerations section. 254 8 References 256 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 257 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 259 Session Initiation Protocol", RFC 3261, June 2002. 261 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 262 (SIP): Locating SIP Servers", RFC 3263, June 2002. 264 [3] Sparks, R., "Problems identified associated with the Session 265 Initiation Protocol's non-INVITE Transaction", 266 draft-sparks-sip-nit-problems (work in progress), February 2004. 268 Author's Address 270 Robert J. Sparks 271 Xten 272 5100 Tennyson Parkway 273 Suite 1000 274 Plano, TX 75024 276 EMail: RjS@xten.com 278 Intellectual Property Statement 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at 300 ietf-ipr@ietf.org. 302 Disclaimer of Validity 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 307 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 308 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 309 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Copyright Statement 314 Copyright (C) The Internet Society (2005). This document is subject 315 to the rights, licenses and restrictions contained in BCP 78, and 316 except as set forth therein, the authors retain all their rights. 318 Acknowledgment 320 Funding for the RFC Editor function is currently provided by the 321 Internet Society.