idnits 2.17.1 draft-ietf-idr-optional-transitive-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 26, 2009) is 5296 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) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track E. Chen 5 Expires: April 29, 2010 Cisco Systems 6 October 26, 2009 8 Error Handling for Optional Transitive BGP Attributes 9 draft-ietf-idr-optional-transitive-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 According to the base BGP specification, a BGP speaker that receives 48 an UPDATE message containing a malformed attribute is required to 49 reset the session over which the offending attribute was received. 50 This behavior is undesirable in the case of optional transitive 51 attributes. This document revises BGP's error-handling rules for 52 optional transitive attributes, and provides guidelines for the 53 authors of documents defining new optional transitive attributes. It 54 also revises the error handling procedures for several existing 55 optional transitive attributes. 57 1. Introduction 59 According to the base BGP specification [RFC4271], a BGP speaker that 60 receives an UPDATE message containing a malformed attribute is 61 required to reset the session over which the offending attribute was 62 received. This behavior is undesirable in the case of optional 63 transitive attributes whose Partial bit is set; the reason is that 64 such attributes may have been propagated without being checked by 65 intermediate routers that do not recognize the attribute -- in effect 66 the attributes may have been tunneled, and when they do reach a 67 router that recognizes and checks them, the session that is reset may 68 not be associated with the router that is at fault. This document 69 revises BGP's error-handling rules for optional transitive 70 attributes, and provides guidelines for the authors of documents 71 defining new optional transitive attributes. It also revises the 72 error handling procedures for several existing optional transitive 73 attributes. Specifically, the error handling procedures of 74 [RFC4271], [RFC1997], and [RFC4360] are revised. 76 Error handling procedures are not revised if the error can be imputed 77 to the direct neighbor. In practice, this is achieved by checking 78 whether the Partial bit is set -- if it is not, the original error 79 handling procedures remain in force. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Revision to Base Specification 89 Section 6.3 of [RFC4271] is revised as follows. The paragraphs 90 related to "any recognized attribute" and "an optional attribute" do 91 not apply to optional transitive attributes received with their 92 Partial bit set -- an error limited to such an attribute SHALL NOT be 93 responded to by sending a NOTIFICATION message or resetting the BGP 94 session. Instead, when such an attribute is determined to be 95 malformed, the UPDATE message containing that attribute SHOULD be 96 treated as though all contained routes had been withdrawn just as if 97 they had been listed in the WITHDRAWN ROUTES field of the UPDATE 98 message, thus causing them to be removed from the Adj-RIB-In 99 according to the procedures of [RFC4271]. In the case of an optional 100 transitive attribute which has no effect on route selection or 101 installation, the malformed attribute MAY instead be discarded and 102 the UPDATE message continue to be processed. 104 An example of an attribute which has no effect on route selection or 105 installation is the AGGREGATOR attribute. 107 A document which specifies an optional transitive attribute MUST 108 provide specifics regarding what constitutes an error for that 109 attribute and how that error is to be handled. 111 Note that the revised error handling only applies when an individual 112 optional transitive attribute is received with its Partial bit set 113 and deemed to be erroneous. In the event that an UPDATE message is 114 deemed to be malformed in any other way then the procedures of 115 [RFC4271] MUST be applied. This is likewise the case if an optional 116 transitive attribute is received whose Partial bit is not set -- this 117 is because the detected error can be imputed to the direct peer. 119 Examples of errors which would continue to be treated according to 120 the procedures of [RFC4271] include the cases where the Total 121 Attribute Length is inconsistent with the message length, or where 122 there is more than one attribute with a given type code. Also, 123 implicit in the foregoing paragraph is the fact that if due to an 124 error, including those in an optional transitive attribute, the other 125 attributes of the UPDATE message cannot be correctly parsed, then the 126 procedures of [RFC4271] continue to apply. 128 In the specific case of incorrect path attribute flag bits -- i.e., a 129 path attribute that is known by its type code to be Optional and 130 Transitive but whose flag bits are not set accordingly -- the 131 behavior specified by [RFC4271] SHALL be followed. (Consider that in 132 the case of such an error, the "tunneling" argument given above does 133 not apply, by definition.) 135 Finally, we observe that in order to treat an UPDATE as though all 136 contained routes had been withdrawn as discussed above, the NLRI 137 field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be 138 successfully parsed. If this were not possible, the UPDATE would 139 necessarily be malformed in some way beyond the scope of this 140 document and therefore, the procedures of [RFC4271] would continue to 141 apply. 143 3. Operational Considerations 145 Although the "treat as withdraw" error-handling behavior defined in 146 Section 2 makes every effort to preserve BGP's correctness, we note 147 that if an UPDATE received on an IBGP session is subjected to this 148 treatment, inconsistent routing within the affected Autonomous System 149 may result. The consequences of inconsistent routing can include 150 long-lived forwarding loops and black holes. While lamentable, this 151 issue is expected to be rare in practice, and more importantly is 152 seen as less problematic than the session-reset behavior it replaces. 154 Even if inconsistent routing does not arise, the "treat as withdraw" 155 behavior can cause either complete unreachability or sub-optimal 156 routing for the destinations whose routes are carried in the affected 157 UPDATE message. 159 Note that "treat as withdraw" is different from discarding an UPDATE 160 message. The latter violates the basic BGP principle of incremental 161 update, and could cause invalid routes to be kept. (See also 162 Appendix A.) 164 For any malformed attribute which is discarded instead of the 165 containing UPDATE being treated as a withdraw as discussed in 166 Section 2, it is critical to consider the potential impact of doing 167 so. In particular, if the attribute in question has or may have an 168 effect on route selection or installation, the presumption is that 169 discarding it is unsafe, unless careful analysis proves otherwise. 170 The analysis should take into account the tradeoff between preserving 171 connectivity and potential side effects. 173 Because of these potential issues, a BGP speaker MUST provide 174 debugging facilities to permit issues caused by malformed optional 175 transitive attributes to be diagnosed. At a minimum, such facilities 176 SHOULD include logging an error when such an attribute is detected. 178 4. Error Handling Procedures for Existing Optional Transitive 179 Attributes 181 4.1. AGGREGATOR 183 The error handling of [RFC4271] is revised as follows: 185 The AGGREGATOR attribute SHALL be considered malformed if any of the 186 following applies: 188 o Its length is not 6 (when the "4-octet AS number capability" is 189 not advertised to, or not received from the peer [RFC4893]). 191 o Its length is not 8 (when the "4-octet AS number capability" is 192 both advertised to, and received from the peer). 194 If the attribute is malformed and its Partial bit is set, either the 195 attribute MUST be discarded or the UPDATE containing it treated as a 196 withdraw as discussed in Section 2. If the attribute is malformed 197 and its Partial bit is clear, the procedures of [RFC4271] MUST be 198 followed with respect to an Optional Attribute Error. 200 4.2. Community 202 The error handling of [RFC1997] is revised as follows: 204 The Community attribute SHALL be considered malformed if its length 205 is not a nonzero multiple of 4. 207 If the attribute is malformed and its Partial bit is set, the update 208 containing it MUST be treated as a withdraw as discussed in 209 Section 2. If the attribute is malformed and its Partial bit is 210 clear, the procedures of [RFC4271] MUST be followed with respect to 211 an Optional Attribute Error. 213 4.3. Extended Community 215 The error handling of [RFC4360] is revised as follows: 217 The Extended Community attribute SHALL be considered malformed if its 218 length is not a nonzero multiple of 8. 220 If the attribute is malformed and its Partial bit is set, the update 221 containing it MUST be treated as a withdraw as discussed in 222 Section 2. If the attribute is malformed and its Partial bit is 223 clear, the procedures of [RFC4271] MUST be followed with respect to 224 an Optional Attribute Error. 226 Note that a BGP speaker MUST NOT treat an unrecognized Extended 227 Community Type or Sub-Type as an error. 229 5. Security Considerations 231 This specification addresses the vulnerability of a BGP speaker to a 232 potential attack whereby a distant attacker can generate a malformed 233 optional transitive attribute that is not recognized by intervening 234 routers (which thus propagate the attribute unchecked) but that 235 causes session resets when it reaches routers that do recognize the 236 given attribute type. 238 In other respects, this specification does not change BGP's security 239 characteristics. 241 6. Acknowledgements 243 The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex 244 Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin 245 Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, 246 Ananth Suryanarayana, and Kaliraj Vairavakkalai for their 247 observations and discussion of this topic. 249 7. IANA Considerations 251 This memo makes no request of IANA. 253 8. References 255 8.1. Normative References 257 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 258 Communities Attribute", RFC 1997, August 1996. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 264 Protocol 4 (BGP-4)", RFC 4271, January 2006. 266 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 267 Communities Attribute", RFC 4360, February 2006. 269 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 270 Number Space", RFC 4893, May 2007. 272 8.2. Informative References 274 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 275 "Multiprotocol Extensions for BGP-4", RFC 4760, 276 January 2007. 278 Appendix A. Why not discard UPDATES? 280 A commonly asked question is "why not simply discard the UPDATE 281 message instead of treating it like a withdraw? Isn't that safer and 282 easier?" The answer is that it might be easier, but it would 283 compromise BGP's correctness so is unsafe. Consider the following 284 example of what might happen if UPDATE messages carrying bad 285 attributes were simply discarded: 287 AS1--AS2 288 \ / 289 \ / 290 AS3 292 o AS1 prefers to reach AS3 directly, and advertises its route to 293 AS2. 295 o AS2 prefers to reach AS3 directly, and advertises its route to 296 AS1. 298 o Connections AS3-AS1 and AS3-AS2 fail simultaneously. 300 o AS1 switches to prefer AS2's route, and sends an update message 301 which includes a withdraw of its previous announcement. The 302 withdraw is bundled with some advertisements. It includes a bad 303 attribute. As a result, AS2 ignores the message. 305 o AS2 switches to prefer AS1's route, and sends an update message 306 which includes a withdraw of its previous announcement. The 307 withdraw is bundled with some advertisements. It includes a bad 308 attribute. As a result, AS1 ignores the message. 310 The end result is that AS1 forwards traffic for AS3 towards AS2, and 311 AS2 forwards traffic for AS3 towards AS1. This is a permanent (until 312 corrected) forwarding loop. 314 Although the example above discusses route withdraws, we observe that 315 in BGP the announcement of a route also withdraws the route 316 previously advertised. The implicit withdraw can be converted into a 317 real withdraw in a number of ways; for example, the previously- 318 announced route might have been accepted by policy, but the new 319 announcement might be rejected by policy. For this reason, the same 320 concerns apply even if explicit withdraws are removed from 321 consideration. 323 Authors' Addresses 325 John G. Scudder 326 Juniper Networks 328 Email: jgs@juniper.net 330 Enke Chen 331 Cisco Systems 333 Email: enkechen@cisco.com