--- 1/draft-ietf-idr-optional-transitive-02.txt 2010-09-28 01:12:14.000000000 +0200 +++ 2/draft-ietf-idr-optional-transitive-03.txt 2010-09-28 01:12:14.000000000 +0200 @@ -1,58 +1,53 @@ Internet Engineering Task Force J. Scudder Internet-Draft Juniper Networks Intended status: Standards Track E. Chen -Expires: September 27, 2010 Cisco Systems - March 26, 2010 +Expires: April 1, 2011 Cisco Systems + September 28, 2010 Error Handling for Optional Transitive BGP Attributes - draft-ietf-idr-optional-transitive-02.txt + draft-ietf-idr-optional-transitive-03.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 undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. 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 existing optional transitive attributes. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. 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/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 27, 2010. + This Internet-Draft will expire on April 1, 2011. Copyright Notice + Copyright (c) 2010 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 @@ -50,21 +45,21 @@ 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 BSD License. + 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 undesirable in the case of optional transitive attributes whose Partial flag is set; the reason is that such attributes may have been propagated without being checked by intermediate routers that do not recognize the attribute -- in effect @@ -166,38 +161,77 @@ -- this is because the detected error can be imputed to the direct peer. Examples of errors which would continue to be treated according to the procedures of [RFC4271] include the cases where the Total Attribute Length is inconsistent with the message length, or where there is more than one attribute with a given type code. Also, implicit in the foregoing paragraph is the fact that if due to an error, including those in an optional transitive attribute, the other attributes of the UPDATE message cannot be correctly parsed, then the - procedures of [RFC4271] continue to apply. + procedures of [RFC4271] continue to apply. Examples of errors that + would continue to be treated according to the procedures of [RFC4271] + include the cases where the Total Attribute Length is inconsistent + with the message length, where the Attribute Length is inconsistent + with the Total Attribute Length, or where there is more than one + attribute with a given type code. Also, implicit in the foregoing + paragraph is the fact that if due to an error, including those in an + optional transitive attribute, the other attributes of the UPDATE + message cannot be correctly parsed, then the procedures of [RFC4271] + continue to apply. In the specific case of incorrect path attribute flags -- i.e., a path attribute that is known by its type code to be Optional and Transitive but whose flags are not set accordingly -- the behavior specified by [RFC4271] SHALL be followed. (Consider that in the case of such an error, the "tunneling" argument given above does not apply, by definition.) Finally, we observe that in order to treat an UPDATE as though all contained routes had been withdrawn as discussed above, the NLRI field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be successfully parsed. If this were not possible, the UPDATE would necessarily be malformed in some way beyond the scope of this document and therefore, the procedures of [RFC4271] would continue to apply. -4. Operational Considerations +4. Parsing of NLRI Fields + + We observe that in order to treat an UPDATE as though all contained + routes had been withdrawn as discussed above, the NLRI field and/or + MP_REACH and MP_UNREACH [RFC4760] attributes need to be successfully + parsed. If this were not possible, the UPDATE would necessarily be + malformed in some way beyond the scope of this document and + therefore, the procedures of [RFC4271] would continue to apply. + + To facilitate the determination of the NLRI field in an UPDATE with + malformed attributes, we strongly RECOMMEND that the MP_REACH or + MP_UNREACH attribute (if present) be encoded as the very first path + attribute in an UPDATE. + + Traditionally the NLRI for the IPv4 unicast address family are + carried immediately following all the attributes in an UPDATE + [RFC4271]. 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. Operational Considerations Although the "treat as withdraw" error-handling behavior defined in Section 3 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 the session-reset behavior it replaces. @@ -218,131 +252,131 @@ 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 malformed optional transitive attributes to be diagnosed. At a minimum, such facilities SHOULD include logging an error when such an attribute is detected. -5. Error Handling Procedures for Existing Optional Transitive +6. Error Handling Procedures for Existing Optional Transitive Attributes -5.1. AGGREGATOR +6.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 handled as 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), the procedures of [RFC4271] MUST be followed with respect to an Optional Attribute Error. -5.2. Community +6.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 handled as 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), the procedures of [RFC4271] MUST be followed with respect to an Optional Attribute Error. -5.3. Extended Community +6.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 handled as 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), the procedures of [RFC4271] MUST be followed with respect to an Optional Attribute Error. Note that a BGP speaker MUST NOT treat an unrecognized Extended Community Type or Sub-Type as an error. -6. Security Considerations +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. -7. Acknowledgements +8. Acknowledgements The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, Ananth Suryanarayana, and Kaliraj Vairavakkalai for their observations and discussion of this topic. The Neighbor-Complete flag was introduced as the result of helpful discussion with Jie Dong and Mach Chen. -8. IANA Considerations +9. IANA Considerations IANA is requested to establish and maintain a registry of BGP Path Attribute Flags. Flags one through four are defined in [RFC4271]. Flag five is defined in Section 2 of this document. Future allocations are to be made according to the IETF Standards Action policy [RFC5226]. -9. References +10. References -9.1. Normative References +10.1. 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. -9.2. Informative References +10.2. Informative References [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Appendix A. Why not discard UPDATES? 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