idnits 2.17.1 draft-kaplan-straw-b2bua-loop-detection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4050 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Kaplan 3 Internet Draft Acme Packet 4 Intended status: Standards Track Victor Pascual 5 Expires: August 30, 2013 Acme Packet 6 February 25, 2013 8 Loop Detection Mechanisms for 9 Session Initiation Protocol (SIP) 10 Back-to-Back User Agents (B2BUAs) 11 draft-kaplan-straw-b2bua-loop-detection-01 13 Abstract 15 SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request 16 routing loops because, as User Agent Clients, they can generate SIP 17 requests with new Max-Forwards values. This document discusses the 18 difficulties associated with loop detection for B2BUAs, and 19 requirements for them to prevent infinite loops. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology...................................................2 62 2. Introduction..................................................2 63 3. Background....................................................3 64 4. B2BUA Loop-Detection Behavior.................................4 65 5. B2BUA Max-Forwards Behavior...................................4 66 6. B2BUA Max-Breadth Behavior....................................4 67 7. Security Considerations.......................................5 68 8. IANA Considerations...........................................5 69 9. Acknowledgments...............................................5 70 10. References...................................................5 71 10.1. Informative References..................................5 72 Authors' Addresses................................................6 74 1. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. The 79 terminology in this document conforms to RFC 2828, "Internet 80 Security Glossary". 82 B2BUA terminology and taxonomy used in this document is based on 83 [draft-b2bua-taxonomy]. 85 2. Introduction 87 SIP provides a means of preventing infinite request forwarding loops 88 in [RFC3261], and a means of mitigating parallel forking 89 amplification floods in [RFC5393]. Neither document normatively 90 defines specific behavior for B2BUAs, however. 92 Unbounded SIP request loops have actually occurred in SIP 93 deployments, numerous times. The cause of loops is usually mis- 94 configuration, but the reason they have been unbounded/unending is 95 they crossed B2BUAs that reset the Max-Forwards value in the SIP 96 requests they generated on their UAC side. Although such behavior 97 is technically legal per [RFC3261] because a B2BUA is a UAC, the 98 resulting unbounded loops have caused service outages and make 99 troubleshooting difficult. 101 Furthermore, [RFC5393] also provides a mechanism to mitigate the 102 impact of parallel forking amplification issues, through the use of 103 a "Max-Breadth" header field. If a B2BUA does not pass on this 104 header field, parallel forking amplification is not mitigated with 105 the [RFC5393] mechanism. 107 This document defines normative requirements for Max-Forwards and 108 Max-Breadth header field behaviors of B2BUAs, in order to mitigate 109 the effect of loops and parallel forking amplification. 111 3. Background 113 Within the context of B2BUAs, the scope of the SIP protocol ends at 114 the UAS side of the B2BUA, and a new one begins on the UAC side. A 115 B2BUA is thus capable of choosing what it wishes to do on its UAC 116 side independently of its UAS side, and still remain compliant to 117 [RFC3261] and its extensions. For example, any B2BUA type defined 118 in [draft-b2bua-taxonomy] other than Proxy-B2BUA may create the SIP 119 request on its UAC side without copying any of the Via header field 120 values received on its UAS side. Indeed there are valid reasons for 121 it to do so; however this prevents the Via-based loop-detection 122 mechanism defined in [RFC3261] and updated by [RFC5393] from 123 detecting SIP request loops any earlier than by reaching a Max- 124 Forwards limit. 126 Some attempts have been made by B2BUA vendors to detect request 127 loops in other ways: by keeping track of the number of outstanding 128 dialog-forming requests for a given caller/called URI pair; or by 129 detecting when they receive and send their own media addressing 130 information too many times in certain cases when they are a Media- 131 plane B2BUA; or by encoding a request instance identifier in some 132 field they believe will pass through other nodes, and detecting when 133 they see the same value too many times. 135 All of these methods are brittle and prone to error, however. They 136 are brittle because the definition of when a value has been seen 137 "too many times" is very hard to accurately determine; requests can 138 and do fork before and after B2BUAs process them, and requests 139 legitimately spiral in some cases, leading to incorrect 140 determination of loops. The mechanisms are prone to error because 141 there can be other B2BUAs in the loop's path that interfere with the 142 particular mechanism being used. 144 Ultimately, the last defense against loops becoming unbounded is to 145 limit how many SIP hops any request can traverse, which is the 146 purpose of the SIP Max-Forwards field value. If B2BUAs were to at 147 least copy and decrement the Max-Forwards header field value from 148 their UAS to the UAC side, loops would not continue indefinitely. 150 4. B2BUA Loop-Detection Behavior 152 A Proxy-B2BUA, as defined in [draft-b2bua-taxonomy], MUST implement 153 the loop-detection mechanism for the Via header field, as defined 154 for a Proxy in [RFC5393]. 156 [Note: should we require all B2BUAs to perform Via-header loop- 157 detection as well, even if they themselves don't forward on the Via 158 headers?] 160 5. B2BUA Max-Forwards Behavior 162 All B2BUA types MUST copy the received Max-Forwards header field 163 from the received SIP request on their UAS side, to any request(s) 164 they generate on their UAC side, and decrement the value, as if they 165 were a Proxy following [RFC3261]. 167 Being a UAS, B2BUAs MUST also check the received Max-Forwards header 168 field and reject or respond to the request if the value is zero, as 169 defined in [RFC3261]. 171 If the received request did not contain a Max-Forwards header field, 172 one MUST be created in any requests generated in the UAC side, which 173 SHOULD be 70, as described for Proxies in section 16.6 part 3 of 174 [RFC3261]. 176 For B2BUAs that remove Record-Route headers, they MUST only perform 177 the copying and checking rules above for out-of-dialog requests. 178 The reason for this is other User Agents might send in-dialog 179 requests using a very low Max-Forwards value, based on the number of 180 Record-Route headers they received. 182 6. B2BUA Max-Breadth Behavior 184 All B2BUA types MUST copy the received Max-Breadth header field from 185 the received SIP request on their UAS side, to any request(s) they 186 generate on their UAC side, as if they were a Proxy following 187 [RFC5393]. 189 B2BUAs of all types MUST follow the requirements imposed on Proxies 190 as described in section 5.3.3 of [RFC5393], including generating the 191 header field if none is received, limiting its maximum value, etc. 193 B2BUAs that generate parallel requests on their UAC side for a 194 single incoming request on the UAS side MUST also follow the rules 195 for Max-Breadth handling in [RFC5393] as if they were a parallel 196 forking Proxy. 198 7. Security Considerations 200 The security implications for parallel forking amplification are 201 documented in section 7 of [RFC5393]. This document does not add 202 any additional issues beyond those discussed in [RFC5393]. 204 Some B2BUAs reset the Max-Forwards and Max-Breadth header field 205 values in order to obfuscate the number of hops a request has 206 already traversed, as a privacy or security concern. Such goals are 207 at odds with the mechanisms in this document, and administrators can 208 decide which they consider more important: obfuscation vs. loop 209 detection. In order to comply with this RFC, manufacturers MUST 210 comply with the normative rules defined herein by default, but MAY 211 provide user-configurable overrides as they see fit. 213 8. IANA Considerations 215 This document makes no request of IANA. 217 9. Acknowledgments 219 Funding for the RFC Editor function is provided by the IETF 220 Administrative Support Activity (IASA). Thanks to Brett Tate for 221 his review of the document. 223 10. References 225 10.1. Informative References 227 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 228 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 229 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 231 [RFC5393] Sparks, R., et al, "Addressing an Amplification 232 Vulnerability in Session Initiation Protocol (SIP) Forking 233 Proxies", RFC 5393, December 2008. 235 [draft-b2bua-taxonomy] Kaplan, H., "A Taxonomy of Session Initiation 236 Protocol (SIP) Back-to-Back User Agents", draft-kaplan-straw- 237 b2bua-taxonomy-00, July 30, 2012. 239 Authors' Addresses 241 Hadriel Kaplan 242 Acme Packet 243 Email: hkaplan@acmepacket.com 245 Victor Pascual 246 Acme Packet 247 Email: vpascual@acmepacket.com