idnits 2.17.1 draft-ietf-idr-optional-transitive-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 26, 2010) is 5117 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 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: September 27, 2010 Cisco Systems 6 March 26, 2010 8 Error Handling for Optional Transitive BGP Attributes 9 draft-ietf-idr-optional-transitive-02.txt 11 Abstract 13 According to the base BGP specification, a BGP speaker that receives 14 an UPDATE message containing a malformed attribute is required to 15 reset the session over which the offending attribute was received. 16 This behavior is undesirable in the case of optional transitive 17 attributes. This document revises BGP's error-handling rules for 18 optional transitive attributes, and provides guidelines for the 19 authors of documents defining new optional transitive attributes. It 20 also introduces a new Path Attribute flag, Neighbor-Complete, to 21 allow more accurate fault-finding. Finally, it revises the error 22 handling procedures for several existing optional transitive 23 attributes. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 27, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 1. Introduction 64 According to the base BGP specification [RFC4271], a BGP speaker that 65 receives an UPDATE message containing a malformed attribute is 66 required to reset the session over which the offending attribute was 67 received. This behavior is undesirable in the case of optional 68 transitive attributes whose Partial flag is set; the reason is that 69 such attributes may have been propagated without being checked by 70 intermediate routers that do not recognize the attribute -- in effect 71 the attributes may have been tunneled, and when they do reach a 72 router that recognizes and checks them, the session that is reset may 73 not be associated with the router that is at fault. This document 74 revises BGP's error-handling rules for optional transitive 75 attributes, and provides guidelines for the authors of documents 76 defining new optional transitive attributes. It also revises the 77 error handling procedures for several existing optional transitive 78 attributes. Specifically, the error handling procedures of 79 [RFC4271], [RFC1997], and [RFC4360] are revised. 81 Error handling procedures are not revised if the error can be imputed 82 to the direct neighbor. A new flag, Neighbor-Complete, is introduced 83 which, when used, allows the direct neighbor's involvement to be 84 determined unequivocally. Imputation of "blame" to the direct 85 neighbor is achieved by checking the Partial flag and the Neighbor- 86 Complete flag. If the Partial flag is clear, or the Neighbor- 87 Complete flag is set, the original error handling procedures remain 88 in force. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Neighbor-Complete Flag Bit 98 It is desirable to know whether a neighbor recognizes, or does not 99 recognize, a given optional transitive attribute. The Partial Path 100 Attribute flag does not provide exactly this information -- it only 101 enables the determination that a given neighbor did understand such 102 an attribute, if the flag is set to zero. However, if the flag is 103 set to one all that can be concluded is that some BGP speaker in the 104 path did not understand the attribute, it cannot be determined 105 whether the speaker in question was the neighbor or some other 106 speaker. 108 To remedy this, we introduce a new Path Attribute Flag to those 109 defined in [RFC4271] Section 4.3. The fifth high-order bit (bit 4) 110 of the Attribute Flags octet is the Neighbor-Complete bit. It 111 indicates whether the neighbor that sent the message recognizes the 112 attribute (if set to one) or does not recognize it (if set to zero). 113 The Neighbor-Complete flag only applies to optional transitive 114 attributes. For other types of attributes the flag MUST be sent as 115 zero and ignored when received. 117 A BGP speaker MUST set the Neighbor-Complete flag to one when sending 118 a recognized, or zero when sending an unrecognized, optional 119 transitive path attribute to its neighbor. 121 The Neighbor-Complete flag is the equivalent of the Partial flag, 122 with two differences. First, it is reset on a hop-by-hop basis. 123 Second, its "polarity" is reversed, with one instead of zero 124 indicating that a neighbor does recognize the attribute. The reason 125 for this difference is that during the period while this 126 specification is being adopted, some BGP speakers will recognize the 127 Neighbor-Complete flag and some will not. Since the previous 128 definition [RFC4271] of bit 4 required it to be sent as zero, the use 129 of one to mean "attribute recognized" allows the recipient of such a 130 flag to unequivocally determine that a neighbor does recognize the 131 given attribute. 133 Use of the flag on receipt is discussed in Section 3. 135 3. Revision to Base Specification 137 Section 6.3 of [RFC4271] is revised as follows. The paragraphs 138 related to "any recognized attribute" and "an optional attribute" do 139 not apply to optional transitive attributes received with their 140 Partial flag set and Neighbor-Complete flag clear -- an error limited 141 to such an attribute SHALL NOT be responded to by sending a 142 NOTIFICATION message or resetting the BGP session. Instead, when 143 such an attribute is determined to be malformed, the UPDATE message 144 containing that attribute SHOULD be treated as though all contained 145 routes had been withdrawn just as if they had been listed in the 146 WITHDRAWN ROUTES field of the UPDATE message, thus causing them to be 147 removed from the Adj-RIB-In according to the procedures of [RFC4271]. 148 In the case of an optional transitive attribute which has no effect 149 on route selection or installation, the malformed attribute MAY 150 instead be discarded and the UPDATE message continue to be processed. 152 An example of an attribute which has no effect on route selection or 153 installation is the AGGREGATOR attribute. 155 A document which specifies an optional transitive attribute MUST 156 provide specifics regarding what constitutes an error for that 157 attribute and how that error is to be handled. 159 Note that the revised error handling only applies when an individual 160 optional transitive attribute is received with its Partial flag set 161 and Neighbor-Complete flag clear and deemed to be erroneous. In the 162 event that an UPDATE message is deemed to be malformed in any other 163 way then the procedures of [RFC4271] MUST be applied. This is 164 likewise the case if an optional transitive attribute is received 165 whose Partial flag is not set or whose Neighbor-Complete flag is set 166 -- this is because the detected error can be imputed to the direct 167 peer. 169 Examples of errors which would continue to be treated according to 170 the procedures of [RFC4271] include the cases where the Total 171 Attribute Length is inconsistent with the message length, or where 172 there is more than one attribute with a given type code. Also, 173 implicit in the foregoing paragraph is the fact that if due to an 174 error, including those in an optional transitive attribute, the other 175 attributes of the UPDATE message cannot be correctly parsed, then the 176 procedures of [RFC4271] continue to apply. 178 In the specific case of incorrect path attribute flags -- i.e., a 179 path attribute that is known by its type code to be Optional and 180 Transitive but whose flags are not set accordingly -- the behavior 181 specified by [RFC4271] SHALL be followed. (Consider that in the case 182 of such an error, the "tunneling" argument given above does not 183 apply, by definition.) 185 Finally, we observe that in order to treat an UPDATE as though all 186 contained routes had been withdrawn as discussed above, the NLRI 187 field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be 188 successfully parsed. If this were not possible, the UPDATE would 189 necessarily be malformed in some way beyond the scope of this 190 document and therefore, the procedures of [RFC4271] would continue to 191 apply. 193 4. Operational Considerations 195 Although the "treat as withdraw" error-handling behavior defined in 196 Section 3 makes every effort to preserve BGP's correctness, we note 197 that if an UPDATE received on an IBGP session is subjected to this 198 treatment, inconsistent routing within the affected Autonomous System 199 may result. The consequences of inconsistent routing can include 200 long-lived forwarding loops and black holes. While lamentable, this 201 issue is expected to be rare in practice, and more importantly is 202 seen as less problematic than the session-reset behavior it replaces. 204 Even if inconsistent routing does not arise, the "treat as withdraw" 205 behavior can cause either complete unreachability or sub-optimal 206 routing for the destinations whose routes are carried in the affected 207 UPDATE message. 209 Note that "treat as withdraw" is different from discarding an UPDATE 210 message. The latter violates the basic BGP principle of incremental 211 update, and could cause invalid routes to be kept. (See also 212 Appendix A.) 214 For any malformed attribute which is discarded instead of the 215 containing UPDATE being treated as a withdraw as discussed in 216 Section 3, it is critical to consider the potential impact of doing 217 so. In particular, if the attribute in question has or may have an 218 effect on route selection or installation, the presumption is that 219 discarding it is unsafe, unless careful analysis proves otherwise. 220 The analysis should take into account the tradeoff between preserving 221 connectivity and potential side effects. 223 Because of these potential issues, a BGP speaker MUST provide 224 debugging facilities to permit issues caused by malformed optional 225 transitive attributes to be diagnosed. At a minimum, such facilities 226 SHOULD include logging an error when such an attribute is detected. 228 5. Error Handling Procedures for Existing Optional Transitive 229 Attributes 231 5.1. AGGREGATOR 233 The error handling of [RFC4271] is revised as follows: 235 The AGGREGATOR attribute SHALL be considered malformed if any of the 236 following applies: 238 o Its length is not 6 (when the "4-octet AS number capability" is 239 not advertised to, or not received from the peer [RFC4893]). 241 o Its length is not 8 (when the "4-octet AS number capability" is 242 both advertised to, and received from the peer). 244 An UPDATE message with a malformed AGGREGATOR attribute SHALL be 245 handled as follows. If its Partial flag is set and its Neighbor- 246 Complete flag is clear, either the attribute MUST be discarded or the 247 UPDATE containing it treated as a withdraw as discussed in Section 3. 248 Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete 249 flag is set), the procedures of [RFC4271] MUST be followed with 250 respect to an Optional Attribute Error. 252 5.2. Community 254 The error handling of [RFC1997] is revised as follows: 256 The Community attribute SHALL be considered malformed if its length 257 is not a nonzero multiple of 4. 259 An UPDATE message with a malformed Community attribute SHALL be 260 handled as follows. If its Partial flag is set and its Neighbor- 261 Complete flag is clear, the update containing it MUST be treated as a 262 withdraw as discussed in Section 3. Otherwise (i.e. if its Partial 263 flag is clear or its Neighbor-Complete flag is set), the procedures 264 of [RFC4271] MUST be followed with respect to an Optional Attribute 265 Error. 267 5.3. Extended Community 269 The error handling of [RFC4360] is revised as follows: 271 The Extended Community attribute SHALL be considered malformed if its 272 length is not a nonzero multiple of 8. 274 An UPDATE message with a malformed Extended Community attribute SHALL 275 be handled as follows. If its Partial flag is set and its Neighbor- 276 Complete flag is clear, the update containing it MUST be treated as a 277 withdraw as discussed in Section 3. Otherwise (i.e. if its Partial 278 flag is clear or its Neighbor-Complete flag is set), the procedures 279 of [RFC4271] MUST be followed with respect to an Optional Attribute 280 Error. 282 Note that a BGP speaker MUST NOT treat an unrecognized Extended 283 Community Type or Sub-Type as an error. 285 6. Security Considerations 287 This specification addresses the vulnerability of a BGP speaker to a 288 potential attack whereby a distant attacker can generate a malformed 289 optional transitive attribute that is not recognized by intervening 290 routers (which thus propagate the attribute unchecked) but that 291 causes session resets when it reaches routers that do recognize the 292 given attribute type. 294 In other respects, this specification does not change BGP's security 295 characteristics. 297 7. Acknowledgements 299 The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex 300 Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin 301 Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, 302 Ananth Suryanarayana, and Kaliraj Vairavakkalai for their 303 observations and discussion of this topic. The Neighbor-Complete 304 flag was introduced as the result of helpful discussion with Jie Dong 305 and Mach Chen. 307 8. IANA Considerations 309 IANA is requested to establish and maintain a registry of BGP Path 310 Attribute Flags. Flags one through four are defined in [RFC4271]. 311 Flag five is defined in Section 2 of this document. Future 312 allocations are to be made according to the IETF Standards Action 313 policy [RFC5226]. 315 9. References 317 9.1. Normative References 319 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 320 Communities Attribute", RFC 1997, August 1996. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 326 Protocol 4 (BGP-4)", RFC 4271, January 2006. 328 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 329 Communities Attribute", RFC 4360, February 2006. 331 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 332 Number Space", RFC 4893, May 2007. 334 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 335 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 336 May 2008. 338 9.2. Informative References 340 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 341 "Multiprotocol Extensions for BGP-4", RFC 4760, 342 January 2007. 344 Appendix A. Why not discard UPDATES? 346 A commonly asked question is "why not simply discard the UPDATE 347 message instead of treating it like a withdraw? Isn't that safer and 348 easier?" The answer is that it might be easier, but it would 349 compromise BGP's correctness so is unsafe. Consider the following 350 example of what might happen if UPDATE messages carrying bad 351 attributes were simply discarded: 353 AS1--AS2 354 \ / 355 \ / 356 AS3 358 o AS1 prefers to reach AS3 directly, and advertises its route to 359 AS2. 361 o AS2 prefers to reach AS3 directly, and advertises its route to 362 AS1. 364 o Connections AS3-AS1 and AS3-AS2 fail simultaneously. 366 o AS1 switches to prefer AS2's route, and sends an update message 367 which includes a withdraw of its previous announcement. The 368 withdraw is bundled with some advertisements. It includes a bad 369 attribute. As a result, AS2 ignores the message. 371 o AS2 switches to prefer AS1's route, and sends an update message 372 which includes a withdraw of its previous announcement. The 373 withdraw is bundled with some advertisements. It includes a bad 374 attribute. As a result, AS1 ignores the message. 376 The end result is that AS1 forwards traffic for AS3 towards AS2, and 377 AS2 forwards traffic for AS3 towards AS1. This is a permanent (until 378 corrected) forwarding loop. 380 Although the example above discusses route withdraws, we observe that 381 in BGP the announcement of a route also withdraws the route 382 previously advertised. The implicit withdraw can be converted into a 383 real withdraw in a number of ways; for example, the previously- 384 announced route might have been accepted by policy, but the new 385 announcement might be rejected by policy. For this reason, the same 386 concerns apply even if explicit withdraws are removed from 387 consideration. 389 Authors' Addresses 391 John G. Scudder 392 Juniper Networks 394 Email: jgs@juniper.net 396 Enke Chen 397 Cisco Systems 399 Email: enkechen@cisco.com