--- 1/draft-ietf-grow-as-path-prepending-00.txt 2020-10-30 12:14:49.319808580 -0700 +++ 2/draft-ietf-grow-as-path-prepending-01.txt 2020-10-30 12:14:49.343809189 -0700 @@ -1,25 +1,25 @@ Network Working Group M. McBride Internet-Draft Futurewei Intended status: Best Current Practice D. Madory -Expires: March 12, 2021 Oracle +Expires: May 3, 2021 Oracle J. Tantsura Apstra R. Raszuk Bloomberg LP H. Li HPE - September 8, 2020 + October 30, 2020 AS Path Prepending - draft-ietf-grow-as-path-prepending-00 + draft-ietf-grow-as-path-prepending-01 Abstract AS Path Prepending provides a tool to manipulate the BGP AS_Path attribute through prepending multiple entries of an AS. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the internet. This document provides guidance,to the internet community, with how best to utilize AS Path @@ -33,21 +33,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 https://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 March 12, 2021. + This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,26 +64,26 @@ 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 4 3.2. Prepending during a routing leak . . . . . . . . . . . . 5 3.3. Prepending to All . . . . . . . . . . . . . . . . . . . . 6 3.4. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Errant announcement . . . . . . . . . . . . . . . . . . . 7 4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 7 5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH attribute which enumerates ASs a route update has traversed. If the UPDATE message is propagated over an external link, then the local AS number is prepended to the AS_PATH attribute, and the NEXT_HOP attribute is updated with an IP address of the router that should be used as a next hop to the network. If the UPDATE message is propagated over an internal link, then the AS_PATH attribute and the @@ -116,20 +116,23 @@ different ASBRs o Preferring one ASBR over another ASBR in the same site o Utilize one path exclusively and another path solely as a backup o Signal to indicate that one path may have a different amount of capacity than another where the lower capacity link still takes traffic + o An ISP doesn't accept traffic engineering using BGP communities. + Prepending is the only option. + The following illustration, from Geoff Hustons Path Prepending in BGP [1], shows how AS Prepending is typically used: +---+ +---+ +---| D |----| F | | +---+ +---+ +---+ +---+ | | A |---| B | | +---+ +---+ | | +---+ +---+ @@ -141,32 +144,33 @@ two instances of its own AS number when advertising its routes to C, then B will now see a different situation, where the AS Path via D represents the shorter path. Through the use of selective prepending E is able to alter the routing decision of B, even though B is not an adjacent neighbour of E. The result is that traffic from A and B will be passed via D and F to reach E, rather than via C. In this way prepending implements action at a distance where the routing decisions made by non-adjacent ASs can be influenced by selective AS Path prepending. - In August 2020 a large ISP had a network outage that affected their - customers and other ISPs. One major problem was that the ISP wasn't - withdrawing BGP routes, the stale routes were continuing to be - announced as legitimate by the down ISP. This caused blackholing of - traffic even when customers had backup ISPs. What could customers do - in this situation? They could change local preference to help send - traffic to the backup ISP. They could send more specifics to the - backup ISP. They could also use AS Path Prepend by prepending the - same amount to both primary and backup ISPs before failure. - Customers could then, during a failure, remove one prepend to the - backup ISP to make it more preferred over the down ISP. This is one, - of several, scenarios where using AS Path Prepend can be beneficial. + To illustrate, in August 2020 a large ISP had a network outage that + affected their customers and other ISPs. One major problem was that + the ISP wasn't withdrawing BGP routes, the stale routes were + continuing to be announced as legitimate by the down ISP. This + caused blackholing of traffic even when customers had backup ISPs. + What could customers do in this situation? They could change local + preference to help send traffic to the backup ISP. They could send + more specifics to the backup ISP. They could also pre-provision the + use of AS Path Prepend to prepend the same AS amount to both primary + and backup ISPs before failure. Customers could then, during a + failure, remove one prepend to the backup ISP to make it more + preferred over the down ISP. This is one, of several, scenarios + where using AS Path Prepend can be beneficial. 3. Problems Since it is so commonly used, what is the problem with the excessive use of AS Path Prepending? Here are a few examples: 3.1. Excessive Prepending The risk of excessive use of AS Path Prepending can be illustrated with real-world examples that have been anonymized using documention @@ -291,33 +296,35 @@ There are various options to provide path preference without needing to use AS Path Prepend: o Use predefined communities that are mapped to a particular behavior when propagated. o Announce more specific routes on the preferred path. o The BGP Origin Code is an attribute that is used for path - selection. The three origin codes are IGP, EGP and Incomplete. - We could advertise paths with IGP or EGP origin over the preferred - path while the other ASBRs (which would otherwise prepend N times) - advertises with an INCOMPLETE origin code. + selection and can be used as a high order tie-breaker. The three + origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of + equivalent length, users could advertise paths, with IGP or EGP + origin, over the preferred path while the other ASBRs (which would + otherwise need to prepend N times) advertises with an INCOMPLETE + origin code. 5. Best Practices Many of the best practices, or lack thereof, can be illustrated from the preceeding examples. Here's a summary of the best current - practices of using AS Path Prepending: + practices when using AS Path Prepending: - o Network operators should ensure prepending is absolutely - necessary. Many of your networks have excessive prepending + o Network operators should ensure prepending is absolutely necessary + as many networks have excessive prepending o There is no need to prepend more than 5 ASs. The following diagram shows that, according to Excessive AS Path Prepending [3], 90% of AS path lengths are 5 ASNs or fewer in length. +------------------------------------+ 90| | | X | 80| X X | | X X | @@ -340,38 +347,39 @@ AS Path Length in IPv4 X Axis = unique AS Paths in millions o Don't prepend ASNs that you don't own. o Prepending-to-all is a self-inflicted and needless risk that serves little purpose. Those excessively prepending their routes should consider this risk and adjust their routing configuration. - o It is not typical to see more than 20 ASs in a AS_PATH in the - Internet today even with the use of AS_Path prepend. The Internet - is typically around 5 ASs deep with the largest AS_PATH being - 16-20 ASNs. Some have added 100 or more AS Path Prepends and - operators should therefore consider limiting the maximum AS-path - length being accepted + o The Internet is typically around 5 ASs deep with the largest + AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path + Prepends and operators should therefore consider limiting the + maximum AS-path length being accepted through aggressive filter + policies. 6. IANA Considerations - 7. Security Considerations - There are no security issues introduced by this draft. + Long prepending may make a network more vulernable to route hijacking + which will exist whenever there is a well connected peer that is + willing to forge their AS_PATH or allows announcements with a + fabricated AS path. 8. Acknowledgement The authors would like to thank Greg Skinner, Randy Bush, Dave - Farmer, Nick Hilliard, Martijn Schmidt, Jakob Heitz, Michael Still - and Geoff Huston for contributing to this document. + Farmer, Nick Hilliard, Martijn Schmidt, Jakob Heitz, Michael Still, + Geoff Huston and Jeffrey Haas for contributing to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .