draft-ietf-grow-as-path-prepending-04.txt   draft-ietf-grow-as-path-prepending-05.txt 
Network Working Group M. McBride Network Working Group M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Updates: 7454, 8195 (if approved) D. Madory Updates: 7454, 8195 (if approved) D. Madory
Intended status: Best Current Practice Kentik Intended status: Best Current Practice Kentik
Expires: January 9, 2022 J. Tantsura Expires: 8 July 2022 J. Tantsura
Microsoft Microsoft
R. Raszuk R. Raszuk
NTT Network Innovations NTT Network Innovations
H. Li H. Li
HPE HPE
J. Heitz J. Heitz
Cisco Cisco
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
July 8, 2021 4 January 2022
AS Path Prepending AS Path Prepending
draft-ietf-grow-as-path-prepending-04 draft-ietf-grow-as-path-prepending-05
Abstract Abstract
AS Path Prepending provides a tool to manipulate the BGP AS_Path AS Path Prepending provides a tool to manipulate the BGP AS_Path
attribute through prepending multiple entries of an AS. AS Path attribute through prepending multiple entries of an AS. AS Path
Prepending is used to deprioritize a route or alternate path. By Prepending is used to deprioritize a route or alternate path. By
prepending the local ASN multiple times, ASs can make advertised AS prepending the local ASN multiple times, ASs can make advertised AS
paths appear artificially longer. Excessive AS Path Prepending has paths appear artificially longer. Excessive AS Path Prepending has
caused routing issues in the internet. This document provides caused routing issues in the internet. This document provides
guidance with the use of AS Path Prepending, including alternative guidance with the use of AS Path Prepending, including alternative
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2022. This Internet-Draft will expire on 8 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Cascading and ripple affect of prepending across the 3.1. Cascading and ripple affect of prepending across the
internet . . . . . . . . . . . . . . . . . . . . . . . . 4 internet . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Excessive Prepending . . . . . . . . . . . . . . . . . . 5 3.2. Excessive Prepending . . . . . . . . . . . . . . . . . . 5
3.3. Prepending during a routing leak . . . . . . . . . . . . 6 3.3. Prepending during a routing leak . . . . . . . . . . . . 6
3.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 7 3.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 7
3.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Errant announcement . . . . . . . . . . . . . . . . . . . 7 3.6. Errant announcement . . . . . . . . . . . . . . . . . . . 8
4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 8 4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 8
5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9 5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH
attribute which enumerates ASs a route update has traversed. If the attribute which enumerates ASs a route update has traversed. If the
UPDATE message is propagated over an external link, then the local AS UPDATE message is propagated over an external link, then the local AS
number is prepended to the AS_PATH attribute, and the NEXT_HOP 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 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 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 propagated over an internal link, then the AS_PATH attribute and the
skipping to change at page 3, line 28 skipping to change at page 3, line 28
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Use Cases 2. Use Cases
There are various reasons that AS Path Prepending is in use today There are various reasons that AS Path Prepending is in use today
including: including:
o Preferring one ISP over another ISP on the same ASBR or across * Preferring one ISP over another ISP on the same ASBR or across
different ASBRs. different ASBRs.
o Preferring one ASBR over another ASBR in the same site or between * Preferring one ASBR over another ASBR in the same site or between
sister sites. sister sites.
o Utilize one path exclusively and another path solely as a backup. * Utilize one path exclusively and another path solely as a backup.
o Signal to indicate that one path may have a different amount of * Signal to indicate that one path may have a different amount of
capacity than another where the lower capacity link still takes capacity than another where the lower capacity link still takes
traffic. traffic.
o Conditionally prefer one ASBR over another at the same site or * Conditionally prefer one ASBR over another at the same site or
between sites for lowest latency path based on geographic between sites for lowest latency path based on geographic
location. location.
o An ISP doesn't accept traffic engineering using BGP communities. * An ISP doesn't accept traffic engineering using BGP communities.
Prepending is the only option. Prepending is the only option.
The following illustration, from Geoff Hustons Path Prepending in BGP The following illustration, from Geoff Hustons Path Prepending in BGP
[1], shows how AS Prepending is typically used: (https://labs.apnic.net/?p=1264), shows how AS Prepending is
typically used:
+---+ +---+ +---+ +---+
+---| D |----| F | +---| D |----| F |
| +---+ +---+ | +---+ +---+
+---+ +---+ | +---+ +---+ |
| A |---| B | | | A |---| B | |
+---+ +---+ 2x<- | +---+ +---+ 2x<- |
| +---+ +---+ | +---+ +---+
+---| C |----| E | +---| C |----| E |
+---+ +---+ +---+ +---+
skipping to change at page 7, line 7 skipping to change at page 7, line 7
prepending-to-all going on right now and during leaks, it doesn't go prepending-to-all going on right now and during leaks, it doesn't go
well for those who make this mistake. While one can debate the well for those who make this mistake. While one can debate the
merits of prepending to a subset of multiple transit providers, it is merits of prepending to a subset of multiple transit providers, it is
difficult to see the utility in prepending to every provider. In difficult to see the utility in prepending to every provider. In
this configuration, the prepending is no longer shaping route this configuration, the prepending is no longer shaping route
propagation. It is simply incentivizing ASs to choose another origin propagation. It is simply incentivizing ASs to choose another origin
if one were to suddenly appear whether by mistake or otherwise. if one were to suddenly appear whether by mistake or otherwise.
3.4. Prepending to All 3.4. Prepending to All
Based on analysis done in 2019, Excessive AS Path Prepending [2], out Based on analysis done in 2019, Excessive AS Path Prepending
of approximately 750,000 routes in the IPv4 global routing table, (https://blogs.oracle.com/internetintelligence/excessive-as-path-
nearly 60,000 BGP routes are prepended to 95% or more of hundreds of prepending-is-a-self-inflicted-vulnerability), out of approximately
BGP sources. About 8% of the global routing table, or 1 out of every 750,000 routes in the IPv4 global routing table, nearly 60,000 BGP
12 BGP routes, is configured with prepends to virtually the entire routes are prepended to 95% or more of hundreds of BGP sources.
internet. The 60,000 routes include entities of every stripe: About 8% of the global routing table, or 1 out of every 12 BGP
governments, financial institutions, even important parts of internet routes, is configured with prepends to virtually the entire internet.
The 60,000 routes include entities of every stripe: governments,
financial institutions, even important parts of internet
infrastructure. infrastructure.
Much of the worst propagation of leaked routes during big leak events Much of the worst propagation of leaked routes during big leak events
have been due to routes being prepended-to-all. AS64505 leak of have been due to routes being prepended-to-all. AS64505 leak of
April 2014 (>320,000 prefixes) was prepended-to-all. And the AS64506 April 2014 (>320,000 prefixes) was prepended-to-all. And the AS64506
leak of June 2015 (>260,000 prefixes) was also prepended-to-all. leak of June 2015 (>260,000 prefixes) was also prepended-to-all.
Prepended-to-all prefixes are those seen as prepended by all (or Prepended-to-all prefixes are those seen as prepended by all (or
nearly all) of the ASs of the internet. In this configuration, nearly all) of the ASs of the internet. In this configuration,
prepending is no longer shaping route propagation but is simply prepending is no longer shaping route propagation but is simply
incentivizing ASs to choose another origin if one were to suddenly incentivizing ASs to choose another origin if one were to suddenly
skipping to change at page 8, line 10 skipping to change at page 8, line 18
announcement. In this incident, AS64496 announced its one prefix announcement. In this incident, AS64496 announced its one prefix
with an extremely long AS path. Someone entered their ASN instead of with an extremely long AS path. Someone entered their ASN instead of
the prepend count 64496 modulo 256 = 252 prepends and when a path the prepend count 64496 modulo 256 = 252 prepends and when a path
lengths exceeded 255, routers crashed lengths exceeded 255, routers crashed
4. Alternatives to AS Path Prepend 4. Alternatives to AS Path Prepend
Various options, to provide path preference without needing to use AS Various options, to provide path preference without needing to use AS
Path Prepend, include: Path Prepend, include:
o Use predefined communities that are mapped to a particular * Use predefined communities that are mapped to a particular
behavior when propagated. behavior when propagated.
o Announce more specific routes on the preferred path. * Announce more specific routes on the preferred path.
o The BGP Origin Code is an attribute that is used for path * The BGP Origin Code is an attribute that is used for path
selection and can be used as a high order tie-breaker. The three 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 origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of
equivalent length, users could advertise paths, with IGP or EGP equivalent length, users could advertise paths, with IGP or EGP
origin, over the preferred path while the other ASBRs (which would origin, over the preferred path while the other ASBRs (which would
otherwise need to prepend N times) advertises with an INCOMPLETE otherwise need to prepend N times) advertises with an INCOMPLETE
origin code. origin code.
o The Multi Exit Discriminator (MED) is an optional non-transitive * The Multi Exit Discriminator (MED) is an optional non-transitive
attribute that can be used to influence path preference instead of attribute that can be used to influence path preference instead of
using as-path. MED is non transitive so it cannot influence an AS using as-path. MED is non transitive so it cannot influence an AS
more then 1 AS hop away. more then 1 AS hop away.
o Local-preference optional non-transitive attribute, above as-path * Local-preference optional non-transitive attribute, above as-path
in bgp path selection, can be used to influence route preference in bgp path selection, can be used to influence route preference
within the local operators AS administrative domain. Local- within the local operators AS administrative domain. Local-
preference can shield the operator domain from traffic shifts off preference can shield the operator domain from traffic shifts off
the preferred path to a de-preferred path caused by excess the preferred path to a de-preferred path caused by excess
prepending done by service providers across the internet. If all prepending done by service providers across the internet. If all
service providers across the internet set local-preference inbound service providers across the internet set local-preference inbound
conditionally with Large Community set on preferred paths, conditionally with Large Community set on preferred paths,
essentially the impacts of route leaks as well as other routing essentially the impacts of route leaks as well as other routing
issues resulting from excess prepending can be mitigated. issues resulting from excess prepending can be mitigated.
skipping to change at page 9, line 33 skipping to change at page 9, line 44
ingressing B, will be shunted to D via local-preference and the route ingressing B, will be shunted to D via local-preference and the route
leak is now mitigated for all downstream AS to the left of B that leak is now mitigated for all downstream AS to the left of B that
prefer the path through B. prefer the path through B.
5. Best Practices 5. Best Practices
Many of the best practices, or lack thereof, can be illustrated from Many of the best practices, or lack thereof, can be illustrated from
the preceeding examples. Here's a summary of the best current the preceeding examples. Here's a summary of the best current
practices when using AS Path Prepending: practices when using AS Path Prepending:
o Network operators should ensure prepending is absolutely necessary * Network operators should ensure prepending is absolutely necessary
as many networks have excessive prepending. It is best to as many networks have excessive prepending. It is best to
innumerate what the routing policies are intended to achieve innumerate what the routing policies are intended to achieve
before concluding that prepending is a solution before concluding that prepending is a solution
o The neighbor you are prepending may have an unconditional * The neighbor you are prepending may have an unconditional
preference for customer routes and prepending doesn't work. It's preference for customer routes and prepending doesn't work. It's
helpful to check with neighbors to see if they will honor the helpful to check with neighbors to see if they will honor the
prepend to avoid wasting effort and potentially causing further prepend to avoid wasting effort and potentially causing further
vulnerabilities. vulnerabilities.
o Use of local-preference inbound on preferred paths between service * Use of local-preference inbound on preferred paths between service
providers to help mitigate the adverse affects of prepending providers to help mitigate the adverse affects of prepending
o There is no need to prepend more than 5 ASs. The following * There is no need to prepend more than 5 ASs. The following
diagram, from the previously referenced AS Path Prepending diagram, from the previously referenced AS Path Prepending
analysis from 2019, shows that 90% of AS path lengths are 5 ASNs analysis from 2019, shows that 90% of AS path lengths are 5 ASNs
or fewer in length. or fewer in length.
+------------------------------------+ +------------------------------------+
90| | 90| |
| X | | X |
80| X X | 80| X X |
| X X | | X X |
70| X X | 70| X X |
skipping to change at page 10, line 30 skipping to change at page 10, line 44
20| X XX | 20| X XX |
| XX XX | | XX XX |
10| XX XXXX | 10| XX XXXX |
|XX XXXXXXXXXXXXXXXXX| |XX XXXXXXXXXXXXXXXXX|
+------------------------------------+ +------------------------------------+
5 10 15 5 10 15
AS Path Length in IPv4 AS Path Length in IPv4
X Axis = unique AS Paths in millions X Axis = unique AS Paths in millions
o Don't prepend ASNs that you don't own. * Don't prepend ASNs that you don't own.
o Prepending-to-all is a self-inflicted and needless risk that * Prepending-to-all is a self-inflicted and needless risk that
serves little purpose. Those excessively prepending their routes serves little purpose. Those excessively prepending their routes
should consider this risk and adjust their routing configuration. should consider this risk and adjust their routing configuration.
o The Internet is typically around 5 ASs deep with the largest * 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 AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path
Prepends and operators should therefore consider limiting the Prepends and operators should therefore consider limiting the
maximum AS-path length being accepted through aggressive filter maximum AS-path length being accepted through aggressive filter
policies. policies.
6. IANA Considerations 6. IANA Considerations
7. Security Considerations 7. Security Considerations
Long prepending may make a network more vulernable to route hijacking Long prepending may make a network more vulernable to route hijacking
which will exist whenever there is a well connected peer that is which will exist whenever there is a well connected peer that is
willing to forge their AS_PATH or allows announcements with a willing to forge their AS_PATH or allows announcements with a
fabricated AS path. fabricated AS path.
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Greg Skinner, Randy Bush, Dave The authors would like to thank Greg Skinner, Randy Bush, Dave
Farmer, Nick Hilliard, Martijn Schmidt, Michael Still, Geoff Huston Farmer, Nick Hilliard, Martijn Schmidt, Michael Still, Geoff Huston
and Jeffrey Haas for contributing to this document. and Jeffrey Haas for contributing to this document.
9. References 9. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 11, line 38 skipping to change at page 12, line 5
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010, DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>. <https://www.rfc-editor.org/info/rfc5737>.
[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP
Large Communities", RFC 8195, DOI 10.17487/RFC8195, June Large Communities", RFC 8195, DOI 10.17487/RFC8195, June
2017, <https://www.rfc-editor.org/info/rfc8195>. 2017, <https://www.rfc-editor.org/info/rfc8195>.
9.2. URIs
[1] https://labs.apnic.net/?p=1264
[2] https://blogs.oracle.com/internetintelligence/excessive-as-path-
prepending-is-a-self-inflicted-vulnerability
Authors' Addresses Authors' Addresses
Mike McBride Mike McBride
Futurewei Futurewei
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Doug Madory Doug Madory
Kentik Kentik
Email: dmadory@kentik.com Email: dmadory@kentik.com
Jeff Tantsura Jeff Tantsura
Microsoft Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
skipping to change at page 12, line 17 skipping to change at page 12, line 25
Email: dmadory@kentik.com Email: dmadory@kentik.com
Jeff Tantsura Jeff Tantsura
Microsoft Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Robert Raszuk Robert Raszuk
NTT Network Innovations NTT Network Innovations
940 Stewart Dr 940 Stewart Dr
Sunnyvale, CA 94085 Sunnyvale, CA 94085
USA United States of America
Email: robert@raszuk.net Email: robert@raszuk.net
Hongwei Li Hongwei Li
HPE HPE
Email: flycoolman@gmail.com Email: flycoolman@gmail.com
Jakob Heitz Jakob Heitz
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: jheitz@cisco.com Email: jheitz@cisco.com
Gyan Mishra Gyan Mishra
Verizon Inc. Verizon Inc.
Email: gyan.s.mishra@verizon.com Email: gyan.s.mishra@verizon.com
 End of changes. 34 change blocks. 
60 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/