--- 1/draft-ietf-idr-error-handling-06.txt 2014-05-07 11:14:21.088745399 -0700 +++ 2/draft-ietf-idr-error-handling-07.txt 2014-05-07 11:14:21.112745988 -0700 @@ -1,23 +1,23 @@ Internet Engineering Task Force E. Chen, Ed. Internet-Draft Cisco Systems, Inc. Updates: 1997, 4271, 4360, 4456, 4760, 5701 (if approved)J. Scudder, Ed. Intended status: Standards Track Juniper Networks -Expires: August 18, 2014 P. Mohapatra - Cumulus Networks, Inc. +Expires: November 8, 2014 P. Mohapatra + Sproute Networks K. Patel Cisco Systems, Inc. - February 14, 2014 + May 7, 2014 Revised Error Handling for BGP UPDATE Messages - draft-ietf-idr-error-handling-06 + draft-ietf-idr-error-handling-07 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 as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering 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." - This Internet-Draft will expire on August 18, 2014. + This Internet-Draft will expire on November 8, 2014. Copyright Notice Copyright (c) 2014 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 @@ -72,39 +72,41 @@ than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Revision to Base Specification . . . . . . . . . . . . . . . 4 3. Parsing of NLRI Fields . . . . . . . . . . . . . . . . . . . 6 3.1. Inconsistency of Attribute Length Fields . . . . . . . . 6 3.2. Syntactic Correctness of NLRI Fields . . . . . . . . . . 7 - 4. Operational Considerations . . . . . . . . . . . . . . . . . 7 - 5. Error Handling Procedures for Existing Attributes . . . . . . 8 - 5.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Operational Considerations . . . . . . . . . . . . . . . . . 8 + 5. Error Handling Procedures for Existing Attributes . . . . . . 9 + 5.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. MULTI_EXIT_DESC . . . . . . . . . . . . . . . . . . . . . 9 5.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 9 - 5.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 10 + 5.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 10 5.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 10 5.9. Extended Community . . . . . . . . . . . . . . . . . . . 10 - 5.10. IPv6 Address Specific BGP Extended Community Attribute . 10 + 5.10. IPv6 Address Specific BGP Extended Community Attribute . 11 5.11. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 11 5.12. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 - Appendix A. Why not discard UPDATE messages? . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 as 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 @@ -227,21 +229,22 @@ of "session reset", "treat-as-withdraw" and "attribute discard" from the strongest to the weakest. A document which specifies a new attribute MUST provide specifics regarding what constitutes an error for that attribute and how that error is to be handled. Finally, we observe that in order to use the approach of "treat-as- withdraw", the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed. If this - is not possible, the procedures of [RFC4271] continue to apply. + is not possible, the procedures of [RFC4271] continue to apply, + meaning that the session MUST be reset and a NOTIFICATION sent. Alternatively the error handling procedures specified in [RFC4760] for disabling a particular AFI/SAFI MAY be followed. One notable case where it would be not possible to successfully parse the NLRI is if the NLRI field is found to be "syntactically incorrect" (see Section 3.2). It can be seen that therefore, this part of [RFC4271] Section 6.3 necessarily continues to apply: The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode MUST be set to Invalid Network Field. @@ -300,20 +303,40 @@ considered to be incorrect if any of the following are true: o The length of any of the included NLRI is inconsistent with the given AFI/SAFI (for example, if an IPv4 NLRI has a length greater than 32 or an IPv6 NLRI has a length greater than 128), o When parsing NLRI contained in the attribute, the length of the last NLRI found exceeds the amount of unconsumed data remaining in the attribute. + o The attribute flags of the attribute are inconsistent with those + specified in [RFC4760]. + + o The length of the MP_UNREACH attribute is less than 3, or the + length of the MP_REACH attribute is less than 5. + +3.3. Typed NLRI + + Certain address families, for example MVPN [RFC7117] and EVPN + [I-D.ietf-l2vpn-evpn] have NLRI that are typed. Since supported type + values with the address family are not expressed in the MP-BGP + capability [RFC4760], it is possible for a BGP speaker to advertise + support for the given address family and sub-address family while + still not supporting a particular type of NLRI within that AFI/SAFI. + + A BGP speaker advertising support for such a typed address family + MUST handle routes with unrecognized NLRI types within that address + family by discarding them, unless the relevant specification for that + address family specifies otherwise. + 4. Operational Considerations Although the "treat-as-withdraw" error-handling behavior defined in Section 2 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. @@ -326,22 +349,21 @@ received. This will help maintain routing consistency in the network. Even if inconsistent routing does not arise, the "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" 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.) + update, and could cause invalid routes to be kept. For any malformed attribute which is handled by the "attribute discard" instead of the "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. @@ -504,28 +526,31 @@ 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. Acknowledgements The authors wish to thank Juan Alcaide, Ron Bonica, Mach Chen, Andy - Davidson, Bruno Decraene, Dong Jie, Rex Fernando, Joel Halpern, Akira - Kato, Miya Kohno, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, - Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Eric Rosen, Rob Shakir, - Naiming Shen, Shyam Sethuram, Ananth Suryanarayana, Kaliraj - Vairavakkalai and Lili Wang for their observations and discussion of - this topic, and review of this document. + Davidson, Bruno Decraene, Rex Fernando, Jeff Haas, Joel Halpern, Dong + Jie, Akira Kato, Miya Kohno, Tony Li, Alton Lo, Shin Miyakawa, Tamas + Mondal, Jonathan Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, + Eric Rosen, Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, + Ananth Suryanarayana, Kaliraj Vairavakkalai and Lili Wang for their + observations and discussion of this topic, and review of this + document. -9. Normative References +9. References + +9.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. @@ -540,78 +565,42 @@ "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012. -Appendix A. Why not discard 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 ---- AS2 - \ / - \ / - \ / - AS3 - - Figure 1 - - 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. +9.2. Informative References - 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. + [I-D.ietf-l2vpn-evpn] + Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. + Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- + evpn-06 (work in progress), March 2014. - 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. + [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. + Kodeboniya, "Multicast in Virtual Private LAN Service + (VPLS)", RFC 7117, February 2014. Authors' Addresses Enke Chen (editor) Cisco Systems, Inc. Email: enkechen@cisco.com + John G. Scudder (editor) Juniper Networks Email: jgs@juniper.net Pradosh Mohapatra - Cumulus Networks, Inc. + Sproute Networks - Email: pmohapat@cumulusnetworks.com + Email: mpradosh@yahoo.com Keyur Patel Cisco Systems, Inc. Email: keyupate@cisco.com