idnits 2.17.1 draft-ietf-idr-error-handling-02.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 (June 17, 2012) is 4303 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 333, 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: December 18, 2012 K. Patel 7 Cisco Systems 8 June 17, 2012 10 Revised Error Handling for BGP UPDATE Messages 11 draft-ietf-idr-error-handling-02.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 December 18, 2012. 48 Copyright Notice 50 Copyright (c) 2012 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 If an attribute appears more than once in an UPDATE message, then all 168 the occurrences of the attribute other than the first one SHALL be 169 discarded and the UPDATE message continue to be processed. 171 When multiple malformed attributes exist in an UPDATE message, if the 172 same approach (either "treat-as-withdraw" or "attribute discard") is 173 specified for the handling of these malformed attributes, then the 174 specified approach MUST be used. Otherwise "treat-as-withdraw" MUST 175 be used. 177 A document which specifies a new attribute MUST provide specifics 178 regarding what constitutes an error for that attribute and how that 179 error is to be handled. 181 Finally, we observe that in order to use the approach of "treat-as- 182 withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH 183 [RFC4760bis] attributes need to be successfully parsed. If this is 184 not possible, the procedures of [RFC4271] continue to apply. 185 Alternatively the error handling procedures specified in [RFC4760bis] 186 for disabling a particular AFI/SAFI MAY be followed. 188 3. Parsing of NLRI Fields 190 To facilitate the determination of the NLRI field in an UPDATE with a 191 malformed attribute, the MP_REACH or MP_UNREACH attribute (if 192 present) SHOULD be encoded as the very first path attribute in an 193 UPDATE as recommended by [RFC4760bis]. An implementation, however, 194 MUST still be prepared to receive these fields in any position. 196 If the encoding of [RFC4271] is used, the NLRI field for the IPv4 197 unicast address family is carried immediately following all the 198 attributes in an UPDATE. When such an UPDATE is received, we observe 199 that the NLRI field can be determined using the "Message Length", 200 "Withdrawn Route Length" and "Total Attribute Length" (when they are 201 consistent) carried in the message instead of relying on the length 202 of individual attributes in the message. 204 4. Operational Considerations 206 Although the "treat-as-withdraw" error-handling behavior defined in 207 Section 2 makes every effort to preserve BGP's correctness, we note 208 that if an UPDATE received on an IBGP session is subjected to this 209 treatment, inconsistent routing within the affected Autonomous System 210 may result. The consequences of inconsistent routing can include 211 long-lived forwarding loops and black holes. While lamentable, this 212 issue is expected to be rare in practice, and more importantly is 213 seen as less problematic than the session-reset behavior it replaces. 215 When a malformed attribute is indeed detected over an IBGP session, 216 we RECOMMEND that routes with the malformed attribute be identified 217 and traced back to the ingress router in the network where the routes 218 were sourced or received externally, and then a filter be applied on 219 the ingress router to prevent the routes from being sourced or 220 received. This will help maintain routing consistency in the 221 network. 223 Even if inconsistent routing does not arise, the "treat-as-withdraw" 224 behavior can cause either complete unreachability or sub-optimal 225 routing for the destinations whose routes are carried in the affected 226 UPDATE message. 228 Note that "treat-as-withdraw" is different from discarding an UPDATE 229 message. The latter violates the basic BGP principle of incremental 230 update, and could cause invalid routes to be kept. (See also 231 Appendix A.) 233 For any malformed attribute which is handled by the "attribute 234 discard" instead of the "treat-as-withdraw" approach, it is critical 235 to consider the potential impact of doing so. In particular, if the 236 attribute in question has or may have an effect on route selection or 237 installation, the presumption is that discarding it is unsafe, unless 238 careful analysis proves otherwise. The analysis should take into 239 account the tradeoff between preserving connectivity and potential 240 side effects. 242 Because of these potential issues, a BGP speaker MUST provide 243 debugging facilities to permit issues caused by a malformed attribute 244 to be diagnosed. At a minimum, such facilities MUST include logging 245 an error listing the NLRI involved, and containing the entire 246 malformed UPDATE message when such an attribute is detected. The 247 malformed UPDATE message SHOULD be analyzed, and the root cause 248 SHOULD be investigated. 250 5. Error Handling Procedures for Existing Optional Attributes 252 5.1. AGGREGATOR 254 The error handling of [RFC4271] is revised as follows: 256 The AGGREGATOR attribute SHALL be considered malformed if any of the 257 following applies: 259 o Its length is not 6 (when the "4-octet AS number capability" is 260 not advertised to, or not received from the peer [RFC4893]). 262 o Its length is not 8 (when the "4-octet AS number capability" is 263 both advertised to, and received from the peer). 265 An UPDATE message with a malformed AGGREGATOR attribute SHALL be 266 handled using the approach of "attribute discard". 268 5.2. Community 270 The error handling of [RFC1997] is revised as follows: 272 The Community attribute SHALL be considered malformed if its length 273 is not a nonzero multiple of 4. 275 An UPDATE message with a malformed Community attribute SHALL be 276 handled using the approach of "treat-as-withdraw". 278 5.3. Extended Community 280 The error handling of [RFC4360] is revised as follows: 282 The Extended Community attribute SHALL be considered malformed if its 283 length is not a nonzero multiple of 8. 285 An UPDATE message with a malformed Extended Community attribute SHALL 286 be handled using the approach of "treat-as-withdraw". 288 Note that a BGP speaker MUST NOT treat an unrecognized Extended 289 Community Type or Sub-Type as an error. 291 6. IANA Considerations 293 This document makes no request of IANA. 295 7. Security Considerations 297 This specification addresses the vulnerability of a BGP speaker to a 298 potential attack whereby a distant attacker can generate a malformed 299 optional transitive attribute that is not recognized by intervening 300 routers (which thus propagate the attribute unchecked) but that 301 causes session resets when it reaches routers that do recognize the 302 given attribute type. 304 In other respects, this specification does not change BGP's security 305 characteristics. 307 8. Acknowledgments 309 The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong 310 Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li, 311 Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk, 312 Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth 313 Suryanarayana, and Kaliraj Vairavakkalai for their observations and 314 discussion of this topic, and review of this document. 316 9. Normative References 318 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 319 Communities Attribute", RFC 1997, August 1996. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 325 Protocol 4 (BGP-4)", RFC 4271, January 2006. 327 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 328 Communities Attribute", RFC 4360, February 2006. 330 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 331 Number Space", RFC 4893, May 2007. 333 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 334 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 335 May 2008. 337 [RFC4760bis] 338 Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 339 "Multiprotocol Extensions for BGP-4", 340 draft-ietf-idr-rfc4760bis-03.txt, work in progress, 341 August 2011. 343 Appendix A. Why not discard UPDATE messages? 345 A commonly asked question is "why not simply discard the UPDATE 346 message instead of treating it like a withdraw? Isn't that safer and 347 easier?" The answer is that it might be easier, but it would 348 compromise BGP's correctness so is unsafe. Consider the following 349 example of what might happen if UPDATE messages carrying bad 350 attributes were simply discarded: 352 AS1 ---- AS2 353 \ / 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 10. Authors' Addresses 391 John G. Scudder 392 Juniper Networks 394 Email: jgs@juniper.net 396 Enke Chen 397 Cisco Systems, Inc. 399 EMail: enkechen@cisco.com 401 Pradosh Mohapatra 402 Cisco Systems, Inc. 404 EMail: pmohapat@cisco.com 405 Keyur Patel 406 Cisco Systems, Inc. 408 EMail: keyupate@cisco.com