idnits 2.17.1 draft-ietf-idr-optional-transitive-04.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 (October 25, 2011) is 4560 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 330, 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: April 26, 2012 K. Patel 7 Cisco Systems 8 October 25, 2011 10 Revised Error Handling for BGP UPDATE Messages 11 draft-ietf-idr-optional-transitive-04.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 optional attributes. Finally, it 23 revises the error handling procedures for several existing 24 attributes. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on April 26, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 1. Introduction 66 According to the base BGP specification [RFC4271], a BGP speaker that 67 receives an UPDATE message containing a malformed attribute is 68 required to reset the session over which the offending attribute was 69 received. This behavior is undesirable as a session reset would 70 impact not only routes with the offending attribute, but also other 71 valid routes exchanged over the session. In the case of optional 72 transitive attributes, the behavior is especially troublesome and may 73 present a potential security vulnerability. The reason is that such 74 attributes may have been propagated without being checked by 75 intermediate routers that do not recognize the attributes -- in 76 effect the attribute may have been tunneled, and when they do reach a 77 router that recognizes and checks them, the session that is reset may 78 not be associated with the router that is at fault. 80 The goal for revising the error handling for UPDATE messages is to 81 minimize the impact on routing by a malformed UPDATE message, while 82 maintaining protocol correctness to the extent possible. This can be 83 achieved largely by maintaining the established session and keeping 84 the valid routes exchanged, but removing the routes carried in the 85 malformed UPDATE from the routing system. 87 This document partially revises the error handling for UPDATE 88 messages, and provides guidelines for the authors of documents 89 defining new optional attributes. Finally, it revises the error 90 handling procedures for several existing attributes. Specifically, 91 the error handling procedures of [RFC4271], [RFC1997], and [RFC4360] 92 are revised. 94 1.1. Specification of Requirements 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Revision to Base Specification 102 The first paragraph of Section 6.3 of [RFC4271] is revised as 103 follows: 105 Old Text: 107 All errors detected while processing the UPDATE message MUST be 108 indicated by sending the NOTIFICATION message with the Error Code 109 UPDATE Message Error. The error subcode elaborates on the specific 110 nature of the error. 112 New text: 114 An error detected while processing the UPDATE message for which a 115 session reset is specified MUST be indicated by sending the 116 NOTIFICATION message with the Error Code UPDATE Message Error. 117 The error subcode elaborates on the specific nature of the error. 119 The error handling of the following case described in Section 6.3 of 120 [RFC4271] remains unchanged: 122 If the Withdrawn Routes Length or Total Attribute Length 123 is too large (i.e., if Withdrawn Routes Length + Total Attribute 124 Length + 23 exceeds the message Length), then the Error Subcode 125 MUST be set to Malformed Attribute List. 127 The error handling of the following case described in Section 6.3 of 128 [RFC4271] is revised 130 If any recognized attribute has Attribute Flags that conflict with 131 the Attribute Type Code, then the Error Subcode MUST be set to 132 Attribute Flags Error. The Data field MUST contain the erroneous 133 attribute (type, length, and value). 135 as follows: 137 If any attribute has Attribute Flags that conflict with the 138 Attribute Type Code, then the error SHOULD be logged, and the 139 Attribute Flags MUST be reset to the correct value. The UPDATE 140 message MUST continue to be processed. 142 The error handling of all other cases described in Section 6.3 of 143 [RFC4271] that specify a session reset is revised as follows. 145 When a path attribute in an UPDATE message is determined to be 146 malformed, the UPDATE message containing that attribute MUST be 147 treated as though all contained routes had been withdrawn just as if 148 they had been listed in the WITHDRAWN ROUTES field (or in the 149 MP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATE 150 message, thus causing them to be removed from the Adj-RIB-In 151 according to the procedures of [RFC4271]. In the case of an 152 attribute which has no effect on route selection or installation, the 153 malformed attribute MAY instead be discarded and the UPDATE message 154 continue to be processed. For the sake of brevity, the former 155 approach is termed "treat-as-withdraw", and the latter as "attribute 156 discard". 158 The approach of "treat-as-withdraw" MUST be used for the error 159 handling of the cases described in Section 6.3 of [RFC4271] that 160 specify a session reset and involve any of the following attributes: 161 ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF. 163 The approach of "attribute discard" MUST be used for the error 164 handling of the cases described in Section 6.3 of [RFC4271] that 165 specify a session reset and involve any of the following attributes: 166 ATOMIC_AGGREGATE and AGGREGATOR. 168 When multiple malformed attributes exist in an UPDATE message, if the 169 same approach (either "treat-as-withdraw" or "attribute discard") is 170 specified for the handling of these malformed attributes, then the 171 specified approach MUST be used. Otherwise "treat-as-withdraw" MUST 172 be used. 174 A document which specifies a new attribute MUST provide specifics 175 regarding what constitutes an error for that attribute and how that 176 error is to be handled. 178 Finally, we observe that in order to use the approach of "treat-as- 179 withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH 180 [RFC4760bis] attributes need to be successfully parsed. If this is 181 not possible, the procedures of [RFC4271] continue to apply. 182 Alternatively the error handling procedures specified in [RFC4760bis] 183 for disabling a particular AFI/SAFI MAY be followed. 185 3. Parsing of NLRI Fields 187 To facilitate the determination of the NLRI field in an UPDATE with a 188 malformed attribute, the MP_REACH or MP_UNREACH attribute (if 189 present) SHOULD be encoded as the very first path attribute in an 190 UPDATE as recommended by [RFC4760bis]. An implementation, however, 191 MUST still be prepared to receive these fields in any position. 193 If the encoding of [RFC4271] is used, the NLRI field for the IPv4 194 unicast address family is carried immediately following all the 195 attributes in an UPDATE. When such an UPDATE is received, we observe 196 that the NLRI field can be determined using the "Message Length", 197 "Withdrawn Route Length" and "Total Attribute Length" (when they are 198 consistent) carried in the message instead of relying on the length 199 of individual attributes in the message. 201 4. Operational Considerations 203 Although the "treat-as-withdraw" error-handling behavior defined in 204 Section 2 makes every effort to preserve BGP's correctness, we note 205 that if an UPDATE received on an IBGP session is subjected to this 206 treatment, inconsistent routing within the affected Autonomous System 207 may result. The consequences of inconsistent routing can include 208 long-lived forwarding loops and black holes. While lamentable, this 209 issue is expected to be rare in practice, and more importantly is 210 seen as less problematic than the session-reset behavior it replaces. 212 When a malformed attribute is indeed detected over an IBGP session, 213 we recommend that routes with the malformed attribute be identified 214 and traced back to the ingress router in the network where the routes 215 were sourced or received externally, and then a filter be applied on 216 the ingress router to prevent the routes from being sourced or 217 received. This will help maintain routing consistency in the 218 network. 220 Even if inconsistent routing does not arise, the "treat-as-withdraw" 221 behavior can cause either complete unreachability or sub-optimal 222 routing for the destinations whose routes are carried in the affected 223 UPDATE message. 225 Note that "treat-as-withdraw" is different from discarding an UPDATE 226 message. The latter violates the basic BGP principle of incremental 227 update, and could cause invalid routes to be kept. (See also 228 Appendix A.) 230 For any malformed attribute which is handled by the "attribute 231 discard" instead of the "treat-as-withdraw" approach, it is critical 232 to consider the potential impact of doing so. In particular, if the 233 attribute in question has or may have an effect on route selection or 234 installation, the presumption is that discarding it is unsafe, unless 235 careful analysis proves otherwise. The analysis should take into 236 account the tradeoff between preserving connectivity and potential 237 side effects. 239 Because of these potential issues, a BGP speaker MUST provide 240 debugging facilities to permit issues caused by a malformed attribute 241 to be diagnosed. At a minimum, such facilities MUST include logging 242 an error listing the NLRI involved, and containing the entire 243 malformed UPDATE message when such an attribute is detected. The 244 malformed UPDATE message SHOULD be analyzed, and the root cause 245 SHOULD be investigated. 247 5. Error Handling Procedures for Existing Optional Attributes 249 5.1. AGGREGATOR 251 The error handling of [RFC4271] is revised as follows: 253 The AGGREGATOR attribute SHALL be considered malformed if any of the 254 following applies: 256 o Its length is not 6 (when the "4-octet AS number capability" is 257 not advertised to, or not received from the peer [RFC4893]). 259 o Its length is not 8 (when the "4-octet AS number capability" is 260 both advertised to, and received from the peer). 262 An UPDATE message with a malformed AGGREGATOR attribute SHALL be 263 handled using the approach of "attribute discard". 265 5.2. Community 267 The error handling of [RFC1997] is revised as follows: 269 The Community attribute SHALL be considered malformed if its length 270 is not a nonzero multiple of 4. 272 An UPDATE message with a malformed Community attribute SHALL be 273 handled using the approach of "treat-as-withdraw". 275 5.3. Extended Community 277 The error handling of [RFC4360] is revised as follows: 279 The Extended Community attribute SHALL be considered malformed if its 280 length is not a nonzero multiple of 8. 282 An UPDATE message with a malformed Extended Community attribute SHALL 283 be handled using the approach of "treat-as-withdraw". 285 Note that a BGP speaker MUST NOT treat an unrecognized Extended 286 Community Type or Sub-Type as an error. 288 6. IANA Considerations 290 This document makes no request of IANA. 292 7. Security Considerations 294 This specification addresses the vulnerability of a BGP speaker to a 295 potential attack whereby a distant attacker can generate a malformed 296 optional transitive attribute that is not recognized by intervening 297 routers (which thus propagate the attribute unchecked) but that 298 causes session resets when it reaches routers that do recognize the 299 given attribute type. 301 In other respects, this specification does not change BGP's security 302 characteristics. 304 8. Acknowledgments 306 The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong 307 Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li, 308 Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk, 309 Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth 310 Suryanarayana, and Kaliraj Vairavakkalai for their observations and 311 discussion of this topic, and review of this document. 313 9. Normative References 315 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 316 Communities Attribute", RFC 1997, August 1996. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 322 Protocol 4 (BGP-4)", RFC 4271, January 2006. 324 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 325 Communities Attribute", RFC 4360, February 2006. 327 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 328 Number Space", RFC 4893, May 2007. 330 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 331 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 332 May 2008. 334 [RFC4760bis] 335 Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 336 "Multiprotocol Extensions for BGP-4", 337 draft-ietf-idr-rfc4760bis-03.txt, work in progress, 338 August 2011. 340 Appendix A. Why not discard UPDATE messages? 342 A commonly asked question is "why not simply discard the UPDATE 343 message instead of treating it like a withdraw? Isn't that safer and 344 easier?" The answer is that it might be easier, but it would 345 compromise BGP's correctness so is unsafe. Consider the following 346 example of what might happen if UPDATE messages carrying bad 347 attributes were simply discarded: 349 AS1 ---- AS2 350 \ / 351 \ / 352 \ / 353 AS3 355 o AS1 prefers to reach AS3 directly, and advertises its route to 356 AS2. 358 o AS2 prefers to reach AS3 directly, and advertises its route to 359 AS1. 361 o Connections AS3-AS1 and AS3-AS2 fail simultaneously. 363 o AS1 switches to prefer AS2's route, and sends an update message 364 which includes a withdraw of its previous announcement. The 365 withdraw is bundled with some advertisements. It includes a bad 366 attribute. As a result, AS2 ignores the message. 368 o AS2 switches to prefer AS1's route, and sends an update message 369 which includes a withdraw of its previous announcement. The 370 withdraw is bundled with some advertisements. It includes a bad 371 attribute. As a result, AS1 ignores the message. 373 The end result is that AS1 forwards traffic for AS3 towards AS2, and 374 AS2 forwards traffic for AS3 towards AS1. This is a permanent (until 375 corrected) forwarding loop. 377 Although the example above discusses route withdraws, we observe that 378 in BGP the announcement of a route also withdraws the route 379 previously advertised. The implicit withdraw can be converted into a 380 real withdraw in a number of ways; for example, the previously- 381 announced route might have been accepted by policy, but the new 382 announcement might be rejected by policy. For this reason, the same 383 concerns apply even if explicit withdraws are removed from 384 consideration. 386 10. Authors' Addresses 388 John G. Scudder 389 Juniper Networks 391 Email: jgs@juniper.net 393 Enke Chen 394 Cisco Systems, Inc. 396 EMail: enkechen@cisco.com 398 Pradosh Mohapatra 399 Cisco Systems, Inc. 401 EMail: pmohapat@cisco.com 402 Keyur Patel 403 Cisco Systems, Inc. 405 EMail: keyupate@cisco.com