Internet Engineering Task Force (IETF) J. ScudderInternet-DraftInternet Draft Juniper Networks Update: 1997, 4271, 4360 (if approved) E. Chen Intendedstatus:Status: Standards TrackE. ChenP. Mohapatra Expires: April1, 201126, 2012 K. Patel Cisco SystemsSeptember 28, 2010October 25, 2011 Revised Error Handling forOptional TransitiveBGPAttributes draft-ietf-idr-optional-transitive-03.txtUPDATE Messages draft-ietf-idr-optional-transitive-04.txt Abstract According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirableinas a session reset would impact not only routes with thecase of optional transitive attributes.offending attribute, but also other valid routes exchanged over the session. This document partially revisesBGP's error-handling rulesthe error handling foroptional transitive attributes,UPDATE messages, and provides guidelines for the authors of documents defining new optionaltransitiveattributes.It also introduces a new Path Attribute flag, Neighbor-Complete, to allow more accurate fault-finding.Finally, it revises the error handling procedures for several existingoptional transitiveattributes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force(IETF).(IETF), its areas, and its working groups. Note that other groups may also distribute working documents asInternet-Drafts. The list of currentInternet-Drafts is at http://datatracker.ietf.org/drafts/current/.Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April1, 2011.26, 2012. Copyright Notice Copyright (c)20102011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction According to the base BGP specification [RFC4271], a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirableinas a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. In the case of optional transitiveattributes whose Partial flag is set;attributes, the behavior is especially troublesome and may present a potential security vulnerability. The reason is that such attributes may have been propagated without being checked by intermediate routers that do not recognize theattributeattributes -- in effect theattributesattribute may have been tunneled, and when they do reach a router that recognizes and checks them, the session that is reset may not be associated with the router that is at fault. The goal for revising the error handling for UPDATE messages is to minimize the impact on routing by a malformed UPDATE message, while maintaining protocol correctness to the extent possible. This can be achieved largely by maintaining the established session and keeping the valid routes exchanged, but removing the routes carried in the malformed UPDATE from the routing system. This document partially revisesBGP's error-handling rulesthe error handling foroptional transitive attributes,UPDATE messages, and provides guidelines for the authors of documents defining new optionaltransitiveattributes.It alsoFinally, it revises the error handling procedures for several existingoptional transitiveattributes. Specifically, the error handling procedures of [RFC4271], [RFC1997], and [RFC4360] are revised.Error handling procedures are not revised if the error can be imputed to the direct neighbor. A new flag, Neighbor-Complete, is introduced which, when used, allows the direct neighbor's involvement to be determined unequivocally. Imputation of "blame" to the direct neighbor is achieved by checking the Partial flag and the Neighbor- Complete flag. If the Partial flag is clear, or the Neighbor- Complete flag is set, the original error handling procedures remain in force.1.1. Specification of RequirementsLanguageThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.Neighbor-Complete Flag Bit It is desirableRevision toknow whether a neighbor recognizes, or does not recognize, a given optional transitive attribute.Base Specification ThePartial Path Attribute flag does not provide exactly this information -- it only enables the determination that a given neighbor did understand such an attribute, if the flag is set to zero. However, if the flag is set to one all that can be concluded is that some BGP speaker in the path did not understand the attribute, it cannot be determined whether the speaker in question was the neighbor or some other speaker. To remedy this, we introduce a new Path Attribute Flag to those defined in [RFC4271]first paragraph of Section4.3. The fifth high-order bit (bit 4)6.3 ofthe Attribute Flags octet[RFC4271] is revised as follows: Old Text: All errors detected while processing theNeighbor-Complete bit. It indicates whether the neighbor that sent theUPDATE messagerecognizes the attribute (if set to one) or does not recognize it (if set to zero). The Neighbor-Complete flag only applies to optional transitive attributes. For other types of attributes the flagMUST besent as zero and ignored when received. A BGP speaker MUST set the Neighbor-Complete flag to one when sending a recognized, or zero whenindicated by sendingan unrecognized, optional transitive path attribute to its neighbor. The Neighbor-Complete flag is the equivalent ofthePartial flag, with two differences. First, it is reset on a hop-by-hop basis. Second, its "polarity" is reversed,NOTIFICATION message withone instead of zero indicating that a neighbor does recognizetheattribute.Error Code UPDATE Message Error. Thereason for this difference is that duringerror subcode elaborates on theperiod while this specification is being adopted, some BGP speakers will recognizespecific nature of theNeighbor-Complete flag and some will not. Sinceerror. New text: An error detected while processing theprevious definition [RFC4271] of bit 4 required it toUPDATE message for which a session reset is specified MUST besent as zero,indicated by sending theuse of one to mean "attribute recognized" allowsNOTIFICATION message with therecipientError Code UPDATE Message Error. The error subcode elaborates on the specific nature ofsuch a flag to unequivocally determine that a neighbor does recognizethegiven attribute. Useerror. The error handling of theflag on receipt is discussedfollowing case described in Section3. 3. Revision to Base Specification Section6.3 of [RFC4271]is revised as follows. The paragraphs related to "any recognized attribute" and "an optional attribute" do not apply to optional transitive attributes received with their Partial flag set and Neighbor-Complete flag clear -- an error limited to such an attribute SHALL NOT be responded to by sending a NOTIFICATION message or resettingremains unchanged: If theBGP session. Instead, when such an attributeWithdrawn Routes Length or Total Attribute Length isdetermined to be malformed, the UPDATE message containing that attribute SHOULD be treated as though all contained routes had been withdrawn just astoo large (i.e., ifthey had been listed in the WITHDRAWN ROUTES field of the UPDATE message, thus causing them to be removed fromWithdrawn Routes Length + Total Attribute Length + 23 exceeds theAdj-RIB-In according tomessage Length), then theproceduresError Subcode MUST be set to Malformed Attribute List. The error handling of[RFC4271]. Inthe following case described in Section 6.3 ofan optional transitive[RFC4271] is revised If any recognized attributewhichhasno effect on route selection or installation,Attribute Flags that conflict with themalformed attribute MAY instead be discarded andAttribute Type Code, then theUPDATE message continue toError Subcode MUST beprocessed. An example of an attribute which has no effect on route selection or installation is the AGGREGATOR attribute. A document which specifies an optional transitive attributeset to Attribute Flags Error. The Data field MUSTprovide specifics regarding what constitutes an error for thatcontain the erroneous attribute (type, length, andhow that error is to be handled. Notevalue). as follows: If any attribute has Attribute Flags that conflict with the Attribute Type Code, then therevisederrorhandling only applies when an individual optional transitive attribute is received with its Partial flag set and Neighbor-Complete flag clearSHOULD be logged, anddeemed tothe Attribute Flags MUST beerroneous. Inreset to theevent that ancorrect value. The UPDATE messageis deemedMUST continue to bemalformed in anyprocessed. The error handling of all otherway then the procedurescases described in Section 6.3 of [RFC4271]MUST be applied. Thisthat specify a session reset islikewise the case if an optional transitiverevised as follows. When a path attribute in an UPDATE message isreceived whose Partial flag is not set or whose Neighbor-Complete flag is set -- this is because the detected error can be imputed to the direct peer. Examples of errors which would continuedetermined to betreated according to the procedures of [RFC4271] include the cases where the Total Attribute Length is inconsistent withmalformed, the UPDATE messagelength, or where there is more than onecontaining that attributewith a given type code. Also, implicitMUST be treated as though all contained routes had been withdrawn just as if they had been listed in theforegoing paragraph is the fact that if due to an error, including thoseWITHDRAWN ROUTES field (or inan optional transitive attribute,theother attributesMP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATEmessage cannot be correctly parsed, then the procedures of [RFC4271] continue to apply. Examples of errors that would continuemessage, thus causing them to betreatedremoved from the Adj-RIB-In according to the procedures of[RFC4271] include[RFC4271]. In thecases wherecase of an attribute which has no effect on route selection or installation, theTotal Attribute Length is inconsistent withmalformed attribute MAY instead be discarded and the UPDATE messagelength, where the Attribute Length is inconsistent withcontinue to be processed. For theTotal Attribute Length, or where there is more than one attribute with a given type code. Also, implicit insake of brevity, theforegoing paragraphformer approach is termed "treat-as-withdraw", and thefact that if due to an error, including those in an optional transitive attribute, the other attributeslatter as "attribute discard". The approach ofthe UPDATE message cannot"treat-as-withdraw" MUST becorrectly parsed, thenused for theprocedureserror handling of[RFC4271] continue to apply. Inthespecific casecases described in Section 6.3 ofincorrect path attribute flags -- i.e., a path attribute[RFC4271] thatis known by its type code to be Optionalspecify a session reset andTransitive but whose flags are not set accordingly --involve any of thebehavior specified by [RFC4271] SHALLfollowing attributes: ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF. The approach of "attribute discard" MUST befollowed. (Consider that inused for thecaseerror handling ofsuch an error,the"tunneling" argument given above does not apply, by definition.) Finally, we observe thatcases described inorder to treat an UPDATE as though all contained routes had been withdrawn as discussed above, the NLRI field and/or MP_REACHSection 6.3 of [RFC4271] that specify a session reset andMP_UNREACH [RFC4760] attributes need to be successfully parsed. If this were not possible,involve any of theUPDATE would necessarily befollowing attributes: ATOMIC_AGGREGATE and AGGREGATOR. When multiple malformed attributes exist insome way beyondan UPDATE message, if the same approach (either "treat-as-withdraw" or "attribute discard") is specified for thescopehandling ofthisthese malformed attributes, then the specified approach MUST be used. Otherwise "treat-as-withdraw" MUST be used. A document which specifies a new attribute MUST provide specifics regarding what constitutes an error for that attribute andtherefore, the procedures of [RFC4271] would continuehow that error is toapply. 4. Parsing of NLRI Fields Webe handled. Finally, we observe that in order totreat an UPDATE as though all contained routes had been withdrawn as discussed above,use the approach of "treat-as- withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH[RFC4760][RFC4760bis] attributes need to be successfully parsed. If thiswereis not possible, theUPDATE would necessarily be malformed in some way beyond the scope of this document and therefore, theprocedures of [RFC4271]wouldcontinue to apply. Alternatively the error handling procedures specified in [RFC4760bis] for disabling a particular AFI/SAFI MAY be followed. 3. Parsing of NLRI Fields To facilitate the determination of the NLRI field in an UPDATE with a malformedattributes, we strongly RECOMMEND thatattribute, the MP_REACH or MP_UNREACH attribute (if present) SHOULD be encoded as the very first path attribute in anUPDATE. TraditionallyUPDATE as recommended by [RFC4760bis]. An implementation, however, MUST still be prepared to receive these fields in any position. If the encoding of [RFC4271] is used, the NLRI field for the IPv4 unicast address familyareis carried immediately following all the attributes in anUPDATE [RFC4271].UPDATE. When such an UPDATE is received, we observe that the NLRI field can be determined using the "Message Length", "Withdrawn Route Length" and "Total Attribute Length" (when they are consistent) carried in the message instead of relying on the length of individual attributes in the message.Furthermore, we observe that the NLRI for the IPv4 unicat address family can equally well be carried in the MP_REACH attribute of an UPDATE when the IPV4 unicast address family capability is shared (i.e., both advertised and received) over a BGP session. For the same sake of better debugging and fault handling, we also RECOMMEND that the MP_REACH attribute be used and be placed as the very first path attribute in an UPDATE in this case. 5.4. Operational Considerations Although the"treat as withdraw""treat-as-withdraw" error-handling behavior defined in Section32 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an IBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and more importantly is seen as less problematic than thesession-reset behavior it replaces.session-reset behavior it replaces. When a malformed attribute is indeed detected over an IBGP session, we recommend that routes with the malformed attribute be identified and traced back to the ingress router in the network where the routes were sourced or received externally, and then a filter be applied on the ingress router to prevent the routes from being sourced or received. This will help maintain routing consistency in the network. Even if inconsistent routing does not arise, the"treat as withdraw""treat-as-withdraw" behavior can cause either complete unreachability or sub-optimal routing for the destinations whose routes are carried in the affected UPDATE message. Note that"treat as withdraw""treat-as-withdraw" is different from discarding an UPDATE message. The latter violates the basic BGP principle of incremental update, and could cause invalid routes to be kept. (See also Appendix A.) For any malformed attribute which isdiscardedhandled by the "attribute discard" instead of thecontaining UPDATE being treated as a withdraw as discussed in Section 3,"treat-as-withdraw" approach, it is critical to consider the potential impact of doing so. In particular, if the attribute in question has or may have an effect on route selection or installation, the presumption is that discarding it is unsafe, unless careful analysis proves otherwise. The analysis should take into account the tradeoff between preserving connectivity and potential side effects. Because of these potential issues, a BGP speaker MUST provide debugging facilities to permit issues caused by a malformedoptional transitive attributesattribute to be diagnosed. At a minimum, such facilitiesSHOULDMUST include logging an error listing the NLRI involved, and containing the entire malformed UPDATE message when such an attribute is detected.6.The malformed UPDATE message SHOULD be analyzed, and the root cause SHOULD be investigated. 5. Error Handling Procedures for Existing OptionalTransitiveAttributes6.1.5.1. AGGREGATOR The error handling of [RFC4271] is revised as follows: The AGGREGATOR attribute SHALL be considered malformed if any of the following applies: o Its length is not 6 (when the "4-octet AS number capability" is not advertised to, or not received from the peer [RFC4893]). o Its length is not 8 (when the "4-octet AS number capability" is both advertised to, and received from the peer). An UPDATE message with a malformed AGGREGATOR attribute SHALL be handledas follows. If its Partial flag is set and its Neighbor- Complete flag is clear, either the attribute MUST be discarded or the UPDATE containing it treated as a withdraw as discussed in Section 3. Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete flag is set),using theproceduresapproach of[RFC4271] MUST be followed with respect to an Optional Attribute Error. 6.2."attribute discard". 5.2. Community The error handling of [RFC1997] is revised as follows: The Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 4. An UPDATE message with a malformed Community attribute SHALL be handledas follows. If its Partial flag is set and its Neighbor- Complete flag is clear, the update containing it MUST be treated as a withdraw as discussed in Section 3. Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete flag is set),using theproceduresapproach of[RFC4271] MUST be followed with respect to an Optional Attribute Error. 6.3."treat-as-withdraw". 5.3. Extended Community The error handling of [RFC4360] is revised as follows: The Extended Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 8. An UPDATE message with a malformed Extended Community attribute SHALL be handledas follows. If its Partial flag is set and its Neighbor- Complete flag is clear, the update containing it MUST be treated as a withdraw as discussed in Section 3. Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete flag is set),using theproceduresapproach of[RFC4271] MUST be followed with respect to an Optional Attribute Error."treat-as-withdraw". Note that a BGP speaker MUST NOT treat an unrecognized Extended Community Type or Sub-Type as an error. 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers (which thus propagate the attribute unchecked) but that causes session resets when it reaches routers that do recognize the given attribute type. In other respects, this specification does not change BGP's security characteristics. 8.AcknowledgementsAcknowledgments The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth Suryanarayana, and Kaliraj Vairavakkalai for their observations and discussion of thistopic. The Neighbor-Complete flag was introduced as the result of helpful discussion with Jie Dong and Mach Chen. 9. IANA Considerations IANA is requested to establishtopic, andmaintain a registry of BGP Path Attribute Flags. Flags one through four are defined in [RFC4271]. Flag five is defined in Section 2review of this document.Future allocations are to be made according to the IETF Standards Action policy [RFC5226]. 10. References 10.1.9. Normative References [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.10.2. Informative References [RFC4760][RFC4760bis] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4",RFC 4760, January 2007.draft-ietf-idr-rfc4760bis-03.txt, work in progress, August 2011. Appendix A. Why not discardUPDATES?UPDATE messages? A commonly asked question is "why not simply discard the UPDATE message instead of treating it like a withdraw? Isn't that safer and easier?" The answer is that it might be easier, but it would compromise BGP's correctness so is unsafe. Consider the following example of what might happen if UPDATE messages carrying bad attributes were simply discarded:AS1--AS2AS1 ---- AS2 \ / \ / \ / AS3 o AS1 prefers to reach AS3 directly, and advertises its route to AS2. o AS2 prefers to reach AS3 directly, and advertises its route to AS1. o Connections AS3-AS1 and AS3-AS2 fail simultaneously. o AS1 switches to prefer AS2's route, and sends an update message which includes a withdraw of its previous announcement. The withdraw is bundled with some advertisements. It includes a bad attribute. As a result, AS2 ignores the message. o AS2 switches to prefer AS1's route, and sends an update message which includes a withdraw of its previous announcement. The withdraw is bundled with some advertisements. It includes a bad attribute. As a result, AS1 ignores the message. The end result is that AS1 forwards traffic for AS3 towards AS2, and AS2 forwards traffic for AS3 towards AS1. This is a permanent (until corrected) forwarding loop. Although the example above discusses route withdraws, we observe that in BGP the announcement of a route also withdraws the route previously advertised. The implicit withdraw can be converted into a real withdraw in a number of ways; for example, the previously- announced route might have been accepted by policy, but the new announcement might be rejected by policy. For this reason, the same concerns apply even if explicit withdraws are removed from consideration. 10. Authors' Addresses John G. Scudder Juniper Networks Email: jgs@juniper.net Enke Chen CiscoSystems Email:Systems, Inc. EMail: enkechen@cisco.com Pradosh Mohapatra Cisco Systems, Inc. EMail: pmohapat@cisco.com Keyur Patel Cisco Systems, Inc. EMail: keyupate@cisco.com