idnits 2.17.1 draft-ietf-idr-error-handling-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (November 16, 2011) is 4507 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) == Unused Reference: 'RFC5226' is defined on line 329, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) J. Scudder 3 Internet Draft Juniper Networks 4 Update: 1997, 4271, 4360 (if approved) E. Chen 5 Intended Status: Standards Track P. Mohapatra 6 Expires: May 17, 2012 K. Patel 7 Cisco Systems 8 November 16, 2011 10 Revised Error Handling for BGP UPDATE Messages 11 draft-ietf-idr-error-handling-00.txt 13 Abstract 15 According to the base BGP specification, a BGP speaker that receives 16 an UPDATE message containing a malformed attribute is required to 17 reset the session over which the offending attribute was received. 18 This behavior is undesirable as a session reset would impact not only 19 routes with the offending attribute, but also other valid routes 20 exchanged over the session. This document partially revises the 21 error handling for UPDATE messages, and provides guidelines for the 22 authors of documents defining new attributes. Finally, it revises 23 the error handling procedures for several existing 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/1id-abstracts.html 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 May 17, 2012. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 According to the base BGP specification [RFC4271], a BGP speaker that 66 receives an UPDATE message containing a malformed attribute is 67 required to reset the session over which the offending attribute was 68 received. This behavior is undesirable as a session reset would 69 impact not only routes with the offending attribute, but also other 70 valid routes exchanged over the session. In the case of optional 71 transitive attributes, the behavior is especially troublesome and may 72 present a potential security vulnerability. The reason is that such 73 attributes may have been propagated without being checked by 74 intermediate routers that do not recognize the attributes -- in 75 effect the attribute may have been tunneled, and when they do reach a 76 router that recognizes and checks them, the session that is reset may 77 not be associated with the router that is at fault. 79 The goal for revising the error handling for UPDATE messages is to 80 minimize the impact on routing by a malformed UPDATE message, while 81 maintaining protocol correctness to the extent possible. This can be 82 achieved largely by maintaining the established session and keeping 83 the valid routes exchanged, but removing the routes carried in the 84 malformed UPDATE from the routing system. 86 This document partially revises the error handling for UPDATE 87 messages, and provides guidelines for the authors of documents 88 defining new attributes. Finally, it revises the error handling 89 procedures for several existing attributes. Specifically, the error 90 handling procedures of [RFC4271], [RFC1997], and [RFC4360] are 91 revised. 93 1.1. Specification of Requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Revision to Base Specification 101 The first paragraph of Section 6.3 of [RFC4271] is revised as 102 follows: 104 Old Text: 106 All errors detected while processing the UPDATE message MUST be 107 indicated by sending the NOTIFICATION message with the Error Code 108 UPDATE Message Error. The error subcode elaborates on the specific 109 nature of the error. 111 New text: 113 An error detected while processing the UPDATE message for which a 114 session reset is specified MUST be indicated by sending the 115 NOTIFICATION message with the Error Code UPDATE Message Error. 116 The error subcode elaborates on the specific nature of the error. 118 The error handling of the following case described in Section 6.3 of 119 [RFC4271] remains unchanged: 121 If the Withdrawn Routes Length or Total Attribute Length 122 is too large (i.e., if Withdrawn Routes Length + Total Attribute 123 Length + 23 exceeds the message Length), then the Error Subcode 124 MUST be set to Malformed Attribute List. 126 The error handling of the following case described in Section 6.3 of 127 [RFC4271] is revised 129 If any recognized attribute has Attribute Flags that conflict with 130 the Attribute Type Code, then the Error Subcode MUST be set to 131 Attribute Flags Error. The Data field MUST contain the erroneous 132 attribute (type, length, and value). 134 as follows: 136 If any attribute has Attribute Flags that conflict with the 137 Attribute Type Code, then the error SHOULD be logged, and the 138 Attribute Flags MUST be reset to the correct value. The UPDATE 139 message MUST continue to be processed. 141 The error handling of all other cases described in Section 6.3 of 142 [RFC4271] that specify a session reset is revised as follows. 144 When a path attribute in an UPDATE message is determined to be 145 malformed, the UPDATE message containing that attribute MUST be 146 treated as though all contained routes had been withdrawn just as if 147 they had been listed in the WITHDRAWN ROUTES field (or in the 148 MP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATE 149 message, thus causing them to be removed from the Adj-RIB-In 150 according to the procedures of [RFC4271]. In the case of an 151 attribute which has no effect on route selection or installation, the 152 malformed attribute MAY instead be discarded and the UPDATE message 153 continue to be processed. For the sake of brevity, the former 154 approach is termed "treat-as-withdraw", and the latter as "attribute 155 discard". 157 The approach of "treat-as-withdraw" MUST be used for the error 158 handling of the cases described in Section 6.3 of [RFC4271] that 159 specify a session reset and involve any of the following attributes: 160 ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF. 162 The approach of "attribute discard" MUST be used for the error 163 handling of the cases described in Section 6.3 of [RFC4271] that 164 specify a session reset and involve any of the following attributes: 165 ATOMIC_AGGREGATE and AGGREGATOR. 167 When multiple malformed attributes exist in an UPDATE message, if the 168 same approach (either "treat-as-withdraw" or "attribute discard") is 169 specified for the handling of these malformed attributes, then the 170 specified approach MUST be used. Otherwise "treat-as-withdraw" MUST 171 be used. 173 A document which specifies a new attribute MUST provide specifics 174 regarding what constitutes an error for that attribute and how that 175 error is to be handled. 177 Finally, we observe that in order to use the approach of "treat-as- 178 withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH 179 [RFC4760bis] attributes need to be successfully parsed. If this is 180 not possible, the procedures of [RFC4271] continue to apply. 181 Alternatively the error handling procedures specified in [RFC4760bis] 182 for disabling a particular AFI/SAFI MAY be followed. 184 3. Parsing of NLRI Fields 186 To facilitate the determination of the NLRI field in an UPDATE with a 187 malformed attribute, the MP_REACH or MP_UNREACH attribute (if 188 present) SHOULD be encoded as the very first path attribute in an 189 UPDATE as recommended by [RFC4760bis]. An implementation, however, 190 MUST still be prepared to receive these fields in any position. 192 If the encoding of [RFC4271] is used, the NLRI field for the IPv4 193 unicast address family is carried immediately following all the 194 attributes in an UPDATE. When such an UPDATE is received, we observe 195 that the NLRI field can be determined using the "Message Length", 196 "Withdrawn Route Length" and "Total Attribute Length" (when they are 197 consistent) carried in the message instead of relying on the length 198 of individual attributes in the message. 200 4. Operational Considerations 202 Although the "treat-as-withdraw" error-handling behavior defined in 203 Section 2 makes every effort to preserve BGP's correctness, we note 204 that if an UPDATE received on an IBGP session is subjected to this 205 treatment, inconsistent routing within the affected Autonomous System 206 may result. The consequences of inconsistent routing can include 207 long-lived forwarding loops and black holes. While lamentable, this 208 issue is expected to be rare in practice, and more importantly is 209 seen as less problematic than the session-reset behavior it replaces. 211 When a malformed attribute is indeed detected over an IBGP session, 212 we RECOMMEND that routes with the malformed attribute be identified 213 and traced back to the ingress router in the network where the routes 214 were sourced or received externally, and then a filter be applied on 215 the ingress router to prevent the routes from being sourced or 216 received. This will help maintain routing consistency in the 217 network. 219 Even if inconsistent routing does not arise, the "treat-as-withdraw" 220 behavior can cause either complete unreachability or sub-optimal 221 routing for the destinations whose routes are carried in the affected 222 UPDATE message. 224 Note that "treat-as-withdraw" is different from discarding an UPDATE 225 message. The latter violates the basic BGP principle of incremental 226 update, and could cause invalid routes to be kept. (See also 227 Appendix A.) 229 For any malformed attribute which is handled by the "attribute 230 discard" instead of the "treat-as-withdraw" approach, it is critical 231 to consider the potential impact of doing so. In particular, if the 232 attribute in question has or may have an effect on route selection or 233 installation, the presumption is that discarding it is unsafe, unless 234 careful analysis proves otherwise. The analysis should take into 235 account the tradeoff between preserving connectivity and potential 236 side effects. 238 Because of these potential issues, a BGP speaker MUST provide 239 debugging facilities to permit issues caused by a malformed attribute 240 to be diagnosed. At a minimum, such facilities MUST include logging 241 an error listing the NLRI involved, and containing the entire 242 malformed UPDATE message when such an attribute is detected. The 243 malformed UPDATE message SHOULD be analyzed, and the root cause 244 SHOULD be investigated. 246 5. Error Handling Procedures for Existing Optional Attributes 248 5.1. AGGREGATOR 250 The error handling of [RFC4271] is revised as follows: 252 The AGGREGATOR attribute SHALL be considered malformed if any of the 253 following applies: 255 o Its length is not 6 (when the "4-octet AS number capability" is 256 not advertised to, or not received from the peer [RFC4893]). 258 o Its length is not 8 (when the "4-octet AS number capability" is 259 both advertised to, and received from the peer). 261 An UPDATE message with a malformed AGGREGATOR attribute SHALL be 262 handled using the approach of "attribute discard". 264 5.2. Community 266 The error handling of [RFC1997] is revised as follows: 268 The Community attribute SHALL be considered malformed if its length 269 is not a nonzero multiple of 4. 271 An UPDATE message with a malformed Community attribute SHALL be 272 handled using the approach of "treat-as-withdraw". 274 5.3. Extended Community 276 The error handling of [RFC4360] is revised as follows: 278 The Extended Community attribute SHALL be considered malformed if its 279 length is not a nonzero multiple of 8. 281 An UPDATE message with a malformed Extended Community attribute SHALL 282 be handled using the approach of "treat-as-withdraw". 284 Note that a BGP speaker MUST NOT treat an unrecognized Extended 285 Community Type or Sub-Type as an error. 287 6. IANA Considerations 289 This document makes no request of IANA. 291 7. Security Considerations 293 This specification addresses the vulnerability of a BGP speaker to a 294 potential attack whereby a distant attacker can generate a malformed 295 optional transitive attribute that is not recognized by intervening 296 routers (which thus propagate the attribute unchecked) but that 297 causes session resets when it reaches routers that do recognize the 298 given attribute type. 300 In other respects, this specification does not change BGP's security 301 characteristics. 303 8. Acknowledgments 305 The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong 306 Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li, 307 Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk, 308 Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth 309 Suryanarayana, and Kaliraj Vairavakkalai for their observations and 310 discussion of this topic, and review of this document. 312 9. Normative References 314 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 315 Communities Attribute", RFC 1997, August 1996. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 321 Protocol 4 (BGP-4)", RFC 4271, January 2006. 323 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 324 Communities Attribute", RFC 4360, February 2006. 326 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 327 Number Space", RFC 4893, May 2007. 329 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 330 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 331 May 2008. 333 [RFC4760bis] 334 Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 335 "Multiprotocol Extensions for BGP-4", 336 draft-ietf-idr-rfc4760bis-03.txt, work in progress, 337 August 2011. 339 Appendix A. Why not discard UPDATE messages? 341 A commonly asked question is "why not simply discard the UPDATE 342 message instead of treating it like a withdraw? Isn't that safer and 343 easier?" The answer is that it might be easier, but it would 344 compromise BGP's correctness so is unsafe. Consider the following 345 example of what might happen if UPDATE messages carrying bad 346 attributes were simply discarded: 348 AS1 ---- AS2 349 \ / 350 \ / 351 \ / 352 AS3 354 o AS1 prefers to reach AS3 directly, and advertises its route to 355 AS2. 357 o AS2 prefers to reach AS3 directly, and advertises its route to 358 AS1. 360 o Connections AS3-AS1 and AS3-AS2 fail simultaneously. 362 o AS1 switches to prefer AS2's route, and sends an update message 363 which includes a withdraw of its previous announcement. The 364 withdraw is bundled with some advertisements. It includes a bad 365 attribute. As a result, AS2 ignores the message. 367 o AS2 switches to prefer AS1's route, and sends an update message 368 which includes a withdraw of its previous announcement. The 369 withdraw is bundled with some advertisements. It includes a bad 370 attribute. As a result, AS1 ignores the message. 372 The end result is that AS1 forwards traffic for AS3 towards AS2, and 373 AS2 forwards traffic for AS3 towards AS1. This is a permanent (until 374 corrected) forwarding loop. 376 Although the example above discusses route withdraws, we observe that 377 in BGP the announcement of a route also withdraws the route 378 previously advertised. The implicit withdraw can be converted into a 379 real withdraw in a number of ways; for example, the previously- 380 announced route might have been accepted by policy, but the new 381 announcement might be rejected by policy. For this reason, the same 382 concerns apply even if explicit withdraws are removed from 383 consideration. 385 10. Authors' Addresses 387 John G. Scudder 388 Juniper Networks 390 Email: jgs@juniper.net 392 Enke Chen 393 Cisco Systems, Inc. 395 EMail: enkechen@cisco.com 397 Pradosh Mohapatra 398 Cisco Systems, Inc. 400 EMail: pmohapat@cisco.com 401 Keyur Patel 402 Cisco Systems, Inc. 404 EMail: keyupate@cisco.com