idnits 2.17.1 draft-ietf-idr-optional-transitive-03.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 (September 28, 2010) is 4952 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: 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 1, 2011 Cisco Systems 6 September 28, 2010 8 Error Handling for Optional Transitive BGP Attributes 9 draft-ietf-idr-optional-transitive-03.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 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). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 1, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 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 flag 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. A new flag, Neighbor-Complete, is introduced 78 which, when used, allows the direct neighbor's involvement to be 79 determined unequivocally. Imputation of "blame" to the direct 80 neighbor is achieved by checking the Partial flag and the Neighbor- 81 Complete flag. If the Partial flag is clear, or the Neighbor- 82 Complete flag is set, the original error handling procedures remain 83 in force. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Neighbor-Complete Flag Bit 93 It is desirable to know whether a neighbor recognizes, or does not 94 recognize, a given optional transitive attribute. The Partial Path 95 Attribute flag does not provide exactly this information -- it only 96 enables the determination that a given neighbor did understand such 97 an attribute, if the flag is set to zero. However, if the flag is 98 set to one all that can be concluded is that some BGP speaker in the 99 path did not understand the attribute, it cannot be determined 100 whether the speaker in question was the neighbor or some other 101 speaker. 103 To remedy this, we introduce a new Path Attribute Flag to those 104 defined in [RFC4271] Section 4.3. The fifth high-order bit (bit 4) 105 of the Attribute Flags octet is the Neighbor-Complete bit. It 106 indicates whether the neighbor that sent the message recognizes the 107 attribute (if set to one) or does not recognize it (if set to zero). 108 The Neighbor-Complete flag only applies to optional transitive 109 attributes. For other types of attributes the flag MUST be sent as 110 zero and ignored when received. 112 A BGP speaker MUST set the Neighbor-Complete flag to one when sending 113 a recognized, or zero when sending an unrecognized, optional 114 transitive path attribute to its neighbor. 116 The Neighbor-Complete flag is the equivalent of the Partial flag, 117 with two differences. First, it is reset on a hop-by-hop basis. 118 Second, its "polarity" is reversed, with one instead of zero 119 indicating that a neighbor does recognize the attribute. The reason 120 for this difference is that during the period while this 121 specification is being adopted, some BGP speakers will recognize the 122 Neighbor-Complete flag and some will not. Since the previous 123 definition [RFC4271] of bit 4 required it to be sent as zero, the use 124 of one to mean "attribute recognized" allows the recipient of such a 125 flag to unequivocally determine that a neighbor does recognize the 126 given attribute. 128 Use of the flag on receipt is discussed in Section 3. 130 3. Revision to Base Specification 132 Section 6.3 of [RFC4271] is revised as follows. The paragraphs 133 related to "any recognized attribute" and "an optional attribute" do 134 not apply to optional transitive attributes received with their 135 Partial flag set and Neighbor-Complete flag clear -- an error limited 136 to such an attribute SHALL NOT be responded to by sending a 137 NOTIFICATION message or resetting the BGP session. Instead, when 138 such an attribute is determined to be malformed, the UPDATE message 139 containing that attribute SHOULD be treated as though all contained 140 routes had been withdrawn just as if they had been listed in the 141 WITHDRAWN ROUTES field of the UPDATE message, thus causing them to be 142 removed from the Adj-RIB-In according to the procedures of [RFC4271]. 143 In the case of an optional transitive attribute which has no effect 144 on route selection or installation, the malformed attribute MAY 145 instead be discarded and the UPDATE message continue to be processed. 147 An example of an attribute which has no effect on route selection or 148 installation is the AGGREGATOR attribute. 150 A document which specifies an optional transitive attribute MUST 151 provide specifics regarding what constitutes an error for that 152 attribute and how that error is to be handled. 154 Note that the revised error handling only applies when an individual 155 optional transitive attribute is received with its Partial flag set 156 and Neighbor-Complete flag clear and deemed to be erroneous. In the 157 event that an UPDATE message is deemed to be malformed in any other 158 way then the procedures of [RFC4271] MUST be applied. This is 159 likewise the case if an optional transitive attribute is received 160 whose Partial flag is not set or whose Neighbor-Complete flag is set 161 -- this is because the detected error can be imputed to the direct 162 peer. 164 Examples of errors which would continue to be treated according to 165 the procedures of [RFC4271] include the cases where the Total 166 Attribute Length is inconsistent with the message length, or where 167 there is more than one attribute with a given type code. Also, 168 implicit in the foregoing paragraph is the fact that if due to an 169 error, including those in an optional transitive attribute, the other 170 attributes of the UPDATE message cannot be correctly parsed, then the 171 procedures of [RFC4271] continue to apply. Examples of errors that 172 would continue to be treated according to the procedures of [RFC4271] 173 include the cases where the Total Attribute Length is inconsistent 174 with the message length, where the Attribute Length is inconsistent 175 with the Total Attribute Length, or where there is more than one 176 attribute with a given type code. Also, implicit in the foregoing 177 paragraph is the fact that if due to an error, including those in an 178 optional transitive attribute, the other attributes of the UPDATE 179 message cannot be correctly parsed, then the procedures of [RFC4271] 180 continue to apply. 182 In the specific case of incorrect path attribute flags -- i.e., a 183 path attribute that is known by its type code to be Optional and 184 Transitive but whose flags are not set accordingly -- the behavior 185 specified by [RFC4271] SHALL be followed. (Consider that in the case 186 of such an error, the "tunneling" argument given above does not 187 apply, by definition.) 189 Finally, we observe that in order to treat an UPDATE as though all 190 contained routes had been withdrawn as discussed above, the NLRI 191 field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be 192 successfully parsed. If this were not possible, the UPDATE would 193 necessarily be malformed in some way beyond the scope of this 194 document and therefore, the procedures of [RFC4271] would continue to 195 apply. 197 4. Parsing of NLRI Fields 199 We observe that in order to treat an UPDATE as though all contained 200 routes had been withdrawn as discussed above, the NLRI field and/or 201 MP_REACH and MP_UNREACH [RFC4760] attributes need to be successfully 202 parsed. If this were not possible, the UPDATE would necessarily be 203 malformed in some way beyond the scope of this document and 204 therefore, the procedures of [RFC4271] would continue to apply. 206 To facilitate the determination of the NLRI field in an UPDATE with 207 malformed attributes, we strongly RECOMMEND that the MP_REACH or 208 MP_UNREACH attribute (if present) be encoded as the very first path 209 attribute in an UPDATE. 211 Traditionally the NLRI for the IPv4 unicast address family are 212 carried immediately following all the attributes in an UPDATE 213 [RFC4271]. When such an UPDATE is received, we observe that the NLRI 214 field can be determined using the "Message Length", "Withdrawn Route 215 Length" and "Total Attribute Length" (when they are consistent) 216 carried in the message instead of relying on the length of individual 217 attributes in the message. 219 Furthermore, we observe that the NLRI for the IPv4 unicat address 220 family can equally well be carried in the MP_REACH attribute of an 221 UPDATE when the IPV4 unicast address family capability is shared 222 (i.e., both advertised and received) over a BGP session. For the 223 same sake of better debugging and fault handling, we also RECOMMEND 224 that the MP_REACH attribute be used and be placed as the very first 225 path attribute in an UPDATE in this case. 227 5. Operational Considerations 229 Although the "treat as withdraw" error-handling behavior defined in 230 Section 3 makes every effort to preserve BGP's correctness, we note 231 that if an UPDATE received on an IBGP session is subjected to this 232 treatment, inconsistent routing within the affected Autonomous System 233 may result. The consequences of inconsistent routing can include 234 long-lived forwarding loops and black holes. While lamentable, this 235 issue is expected to be rare in practice, and more importantly is 236 seen as less problematic than the session-reset behavior it replaces. 238 Even if inconsistent routing does not arise, the "treat as withdraw" 239 behavior can cause either complete unreachability or sub-optimal 240 routing for the destinations whose routes are carried in the affected 241 UPDATE message. 243 Note that "treat as withdraw" is different from discarding an UPDATE 244 message. The latter violates the basic BGP principle of incremental 245 update, and could cause invalid routes to be kept. (See also 246 Appendix A.) 248 For any malformed attribute which is discarded instead of the 249 containing UPDATE being treated as a withdraw as discussed in 250 Section 3, it is critical to consider the potential impact of doing 251 so. In particular, if the attribute in question has or may have an 252 effect on route selection or installation, the presumption is that 253 discarding it is unsafe, unless careful analysis proves otherwise. 254 The analysis should take into account the tradeoff between preserving 255 connectivity and potential side effects. 257 Because of these potential issues, a BGP speaker MUST provide 258 debugging facilities to permit issues caused by malformed optional 259 transitive attributes to be diagnosed. At a minimum, such facilities 260 SHOULD include logging an error when such an attribute is detected. 262 6. Error Handling Procedures for Existing Optional Transitive 263 Attributes 265 6.1. AGGREGATOR 267 The error handling of [RFC4271] is revised as follows: 269 The AGGREGATOR attribute SHALL be considered malformed if any of the 270 following applies: 272 o Its length is not 6 (when the "4-octet AS number capability" is 273 not advertised to, or not received from the peer [RFC4893]). 275 o Its length is not 8 (when the "4-octet AS number capability" is 276 both advertised to, and received from the peer). 278 An UPDATE message with a malformed AGGREGATOR attribute SHALL be 279 handled as follows. If its Partial flag is set and its Neighbor- 280 Complete flag is clear, either the attribute MUST be discarded or the 281 UPDATE containing it treated as a withdraw as discussed in Section 3. 282 Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete 283 flag is set), the procedures of [RFC4271] MUST be followed with 284 respect to an Optional Attribute Error. 286 6.2. Community 288 The error handling of [RFC1997] is revised as follows: 290 The Community attribute SHALL be considered malformed if its length 291 is not a nonzero multiple of 4. 293 An UPDATE message with a malformed Community attribute SHALL be 294 handled as follows. If its Partial flag is set and its Neighbor- 295 Complete flag is clear, the update containing it MUST be treated as a 296 withdraw as discussed in Section 3. Otherwise (i.e. if its Partial 297 flag is clear or its Neighbor-Complete flag is set), the procedures 298 of [RFC4271] MUST be followed with respect to an Optional Attribute 299 Error. 301 6.3. Extended Community 303 The error handling of [RFC4360] is revised as follows: 305 The Extended Community attribute SHALL be considered malformed if its 306 length is not a nonzero multiple of 8. 308 An UPDATE message with a malformed Extended Community attribute SHALL 309 be handled as follows. If its Partial flag is set and its Neighbor- 310 Complete flag is clear, the update containing it MUST be treated as a 311 withdraw as discussed in Section 3. Otherwise (i.e. if its Partial 312 flag is clear or its Neighbor-Complete flag is set), the procedures 313 of [RFC4271] MUST be followed with respect to an Optional Attribute 314 Error. 316 Note that a BGP speaker MUST NOT treat an unrecognized Extended 317 Community Type or Sub-Type as an error. 319 7. Security Considerations 321 This specification addresses the vulnerability of a BGP speaker to a 322 potential attack whereby a distant attacker can generate a malformed 323 optional transitive attribute that is not recognized by intervening 324 routers (which thus propagate the attribute unchecked) but that 325 causes session resets when it reaches routers that do recognize the 326 given attribute type. 328 In other respects, this specification does not change BGP's security 329 characteristics. 331 8. Acknowledgements 333 The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex 334 Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin 335 Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, 336 Ananth Suryanarayana, and Kaliraj Vairavakkalai for their 337 observations and discussion of this topic. The Neighbor-Complete 338 flag was introduced as the result of helpful discussion with Jie Dong 339 and Mach Chen. 341 9. IANA Considerations 343 IANA is requested to establish and maintain a registry of BGP Path 344 Attribute Flags. Flags one through four are defined in [RFC4271]. 345 Flag five is defined in Section 2 of this document. Future 346 allocations are to be made according to the IETF Standards Action 347 policy [RFC5226]. 349 10. References 351 10.1. Normative References 353 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 354 Communities Attribute", RFC 1997, August 1996. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 360 Protocol 4 (BGP-4)", RFC 4271, January 2006. 362 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 363 Communities Attribute", RFC 4360, February 2006. 365 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 366 Number Space", RFC 4893, May 2007. 368 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 369 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 370 May 2008. 372 10.2. Informative References 374 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 375 "Multiprotocol Extensions for BGP-4", RFC 4760, 376 January 2007. 378 Appendix A. Why not discard UPDATES? 380 A commonly asked question is "why not simply discard the UPDATE 381 message instead of treating it like a withdraw? Isn't that safer and 382 easier?" The answer is that it might be easier, but it would 383 compromise BGP's correctness so is unsafe. Consider the following 384 example of what might happen if UPDATE messages carrying bad 385 attributes were simply discarded: 387 AS1--AS2 388 \ / 389 \ / 390 AS3 392 o AS1 prefers to reach AS3 directly, and advertises its route to 393 AS2. 395 o AS2 prefers to reach AS3 directly, and advertises its route to 396 AS1. 398 o Connections AS3-AS1 and AS3-AS2 fail simultaneously. 400 o AS1 switches to prefer AS2's route, and sends an update message 401 which includes a withdraw of its previous announcement. The 402 withdraw is bundled with some advertisements. It includes a bad 403 attribute. As a result, AS2 ignores the message. 405 o AS2 switches to prefer AS1's route, and sends an update message 406 which includes a withdraw of its previous announcement. The 407 withdraw is bundled with some advertisements. It includes a bad 408 attribute. As a result, AS1 ignores the message. 410 The end result is that AS1 forwards traffic for AS3 towards AS2, and 411 AS2 forwards traffic for AS3 towards AS1. This is a permanent (until 412 corrected) forwarding loop. 414 Although the example above discusses route withdraws, we observe that 415 in BGP the announcement of a route also withdraws the route 416 previously advertised. The implicit withdraw can be converted into a 417 real withdraw in a number of ways; for example, the previously- 418 announced route might have been accepted by policy, but the new 419 announcement might be rejected by policy. For this reason, the same 420 concerns apply even if explicit withdraws are removed from 421 consideration. 423 Authors' Addresses 425 John G. Scudder 426 Juniper Networks 428 Email: jgs@juniper.net 430 Enke Chen 431 Cisco Systems 433 Email: enkechen@cisco.com