BGP Route Hijack – What can be done Today?

Protecting your Business, Customers, & the Internet from BGP Route Hijack Chaos?

(DRAFT – Version 0.9)

The Internet is glued together with the Board Gateway Protocol (BGP). It may not be perceived as the “perfect” protocol, but it has delivered a transformative global network that spans the Internet and all telecommunications. It is stable, transparent, and offers each organization (Autonomous System) an ability to control who they BGP peer, how they BGP Peer, what routes are sent on their BGP Peers, what routes are received on the BGP Peers, and where the BGP peering takes place. This flexibility has worked for over 25 years of BGP the Internet.

Given this, all organizations need to be mindful of the BGP Hijacking Risk. BGP Hijacking happens when an organization who was not officially allocated an ASN or an IP address block advertises out their ASN. This “hijacks” traffic to their ASN. These BGP Hijacks are statistically human errors (mistakes) which are seen on the Internet and fixed. Some of these mistakes have had a huge impact on the stability of the Internet. A statistical minority of BGP Hijacking are malicious. These are intentional BGP Hijacks done for the gain of others (SPAM injection, a man in the middle, attacks, disruptions, etc).

Are you ready for BGP Hijacks? Are you ready for BGP Disruption?

Organizations are advised to have BGP Hijack Action and Reaction Plans. An up to date BGP Hijack Risk Mitigation plan is essential to CxOs working in Telco, CSP, ISP, and Cloud Operator. These CxOs must be accountable to their shareholders and constituents who expect the services to be resiliently interconnected with the rest of the world.

This guide is a tool for anyone building BGP Hijack Risk Mitigation Plans. It is an evolving reference tool based on a list of Principles and Recommendations. The object is to provide a single source of tools, examples, and configurations that would help anyone build their BGP Hijack Risk Mitigation Plan.

BGP Hijack Reaction Plans Need to Focus on Critical Services. BGP Hijacks can target a range of services. A “Kapela” BGP Hijack can create a man in the middle to intercept traffic (included encrypted traffic). Hijacking a DNS Authoritative segment would have all the DNS queries for a domain go to a hijacker’s DNS server, pointing everyone for those domains on the Authoritative DNS (aDNS) server be routed to hijacker controlled resources. Malicious BGP Hijacking is a tool to achieve a miscreant’s goal.

The BGP Hijack Prevention Checklist

Some of the items in this checklist are pointed out in the blog post Does the Internet “End” at 500K routes? And the Operator’s Security Toolkit. As with anything, we are constantly looking for a way to improve our communications to make it easier for people in organizations to take action.

The BGP Hijack Action and Reaction checklist uses core principles which each builds resilience into the deployed BGP policies. You do not need to execute all of them all at once. Each “layer” will add more BGP resilience into your organization’s interconnection architecture.


Principle: Global Interconnection Health is a CxO Priority.

Every Business depends on their interconnection to the Internet/Telecom. That interconnection is dependent on BGP. Any large organization leadership needs to ask their staff questions:

Q. How are we connected to the Internet?

Q. How are we protecting our BGP Routes on the Internet?

Q. How do we make sure we don’t make a BGP mistake? How do we make sure we do not advertise “YouTube?”

Q. Explain to me in simple terms, our BGP based interconnection policy?

Q. What is our BGP Crisis Reaction Plan? What do we do when someone tries to BGP Hijack us from the other side of the planet?

Q. How would we know if we’re being attacked through a BGP Hijack?

Principle: Think BGP Hijacking Risk Minimization is a Layered Solution

Projecting against BGP Hijacks is not a “one tool” approach. Organizations should view this as a layered approach. Start with the essentials. Then move to tighter peering agreements. Once those tighter peering arrangements are set up, you move to a Peerlock model. This builds an island or resiliency around your ASN. Once all of that is done, the organization would be ready to move to BGPSEC.

Layer 1 – The BGP Peering Essentials

Many of the most critical BGP Route Hijack issues are minimized through BGP Peering Essentials. These essentials are provided by the router vendors and provide a guideline of what needs to be filtered where. Much of the BGP Security risk can be reduced if Telcos, ISPs, and other large networks just deploy this first layer. The problem is that as of Sept 2018, most do not deploy these basics.

There is no point pushing for BGPSEC RPKI Route Validation deployments when the basics are not deployed. The good news is the vast library of materials to help organizations deploy these essentials. The reference guide BGP Route Hijack – What can be done Today? Is a place to start, but a search for “BGP Security BCPs” will point out a range of materials can organizations can tap into.

Layer 2 – Mutually Agreed Norms for Routing Security (MANRS)

The second layer is the core principles outlined in Mutually Agreed Norms on Routing Security (MANRS). MANRS is a collection of best practices agreed to by major Operators around the world. MANRS is an commitment to each other that a signatory will deploy core security essentials which include BGP Routing Security. While the first layer would also include BGP security principles, MANRS take the practice several steps further – including Source Address Validation, Human Coordination, and Global Validation.

“Are you a MANRS Signatory?” “Why are you not a MANRS Signatory?” “If you have committed MANRS, can you walk through how you are protecting my organization from BGP Hijacks?

These are all questions all organization should be asking their Internet and Telecom providers.

For those interested, the Internet Society has provided everyone on the Internet a MANRS online tutorial. https://www.internetsociety.org/tutorials/manrs/

Layer 3 – Build a BGP Island of Resilience with Peer-Lock

Job Snijders <job@ntt.net> is leading the Internet community to deploy BGP Security resiliency with the tools available today. BPG Peer-Lock is an evolution of how we set up a BGP Peering session. We use BGP Peer-Lock to lock down “known” peering relationships from all of your peers. For example, we know PCCW is not upstream Operator for AT&T. We also know AT&T is not upstream Operator for PCCW. In other words, AT&T and PCCW are Tier 1 peers who will never provide transit to each other. That means when we see this AS_Path in a BGP prefix advertisement AS_PATH 2914_3491_7018 we would not it is garbage! (NTT_PCCW_AT&T).

BGP Peer-Lock requires people to take more time with their peers and transit operators. With that time, you can build an island of BGP Security Resiliency by more robust AS Path Filters which Whitelist KNOWN GOOD BEHAVIOR.

Layer 4 – RPKI Route Origin Validation

Resource Public Key Infrastructure (RPKI) is a public security key infrastructure that we use to validate who is authorized to advertise which routes from where. It has taken decades of work on the BGPSEC architecture, but as of mid-2018, we have our first production deployments of ASNs who have RPKI Route Origin Validation turned on. That means Layers 1 – 3 are critical to preparing for the key objective, large-scale deployment of RPKI Route Origin Validation.


Principle: BGP Hijacking Risk Minimization is a Comprehensive Strategy

You cannot minimize your organization’s BGP Hijacking Risk in isolation. You require a comprehensive strategy that goes beyond the BGP, IRR, and internal processes.


Recommendation: Have everyone in your Network Organization Understand the Hijacking Risk and Essential Tools to Minimize through the Internet Society’s MANRS Tutorial.

Mutually Agreed Norms on Routing Security (MANRS) establishes a baseline that all Operators are encouraged to deploy to build a collective Internet community security/resiliency. The Internet Society has created an interactive tutorial that provides a foundation for all people involved with the Operator’s Operations:

ISOC’s Inforum Course: Mutually Agreed Norms for Routing Security
https://www.internetsociety.org/inforum/manrs/

The materials are crafted in a way that all technical levels of experience would be able to complete the tutorial. At the end of the tutorial, people would have a solid understanding of the community expectations for which we – as all telecommunications and Internet organizations – agree to interoperate.

As seen in the additional recommendations, MANRS is a foundation, but not the only recommendations to build BGP Hijack resistance into your architecture.


Recommendation: Grasp the risk from BGP Hijacking. Understand the BGP Hijacking Threat is Real, it has happened and will happen again. It will be a while before we have a massive deployment of BGPSEC and RPKI throughout all telecom and the world.

First, look back at the BGP, RTBH, and other training videos from the early 2000s @ NANOG, APRICOT, and RIPE. The concept of moving traffic around the Internet is core to the Internet.

Second, watch NANOG 44 – Stealing the Internet by Anton Kapela, 5Nines Data Alex Pilosov, Pilsoft

Abstract: https://www.nanog.org/meetings/abstract?id=878

Slides: https://www.nanog.org/meetings/nanog44/presentations/Tuesday/Kapela_steal_internet_N44.pdf

Video: https://youtu.be/JmCyJtlMT18

Nick Feamster has a good YouTube explanation on the Kapala Attack on BGP that is worth watching.

This is a talk linking back to Anton’s reaction to the DEFCON 16 talk: Stealing The Internet – A Routed, Wide-area, Man in the Middle Attack

Slides: https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

Video & Slides: https://media.defcon.org/DEF%20CON%2016/DEF%20CON%2016%20slides/DEF%20CON%2016%20Hacking%20Conference%20Presentation%20By%20Kapela%20and%20Pilosov%20-%20Stealing%20the%20Internet%20-%20Slides.m4v

Third, listen to NANOG 45 – Hijacking and Tools by Joel Jaeggli and Andree Toonk

Abstract: https://www.nanog.org/meetings/abstract?id=1332

Slides: https://www.nanog.org/meetings/nanog45/presentations/Sunday/Jaeggli_hijacking_detection_N45.pdf

https://www.nanog.org/meetings/nanog45/presentations/Sunday/Toonk_bgpmon_N45.pdf

Forth, listen to the NANOG 46 – Hijacking Mitigation: Something is Better Than Nothing:

Abstract: https://www.nanog.org/meetings/abstract?id=1379

Video: https://youtu.be/zBBSOFafkuo

Slides https://www.nanog.org/meetings/nanog46/presentations/Monday/Daly_Prefix_Hijack_N46.pdf

Finally, please watch the NANOG 63 2015 talk from Andree Toonk – Recent BGP routing incidents – malicious or not

Abstract: https://www.nanog.org/meetings/abstract?id=2476

Slides: https://www.nanog.org/sites/default/files/monday_general_bgp_toonk_63.18.pdf

Video: https://www.youtube.com/watch?v=t7ilZxXFYYQ


Recommendation: Review all the BGP Best Common Practices (BCPs) and inspect your network’s practices and procedures. Review the BCP gaps, areas of improvement, then build an action plan to iterate improvements.

BGP Hijacking Risk can be minimized through practical BGP BCPs for deployment and operations. A typical BGP Peering session would have the policy applied in two directions:

  • Ingress BGP Policy to control all prefixes which are sent to the ASN. This Ingress filter should be in sync with the peer’s Egress BGP Policy. The Ingress BGP policy is designed to be explicit deny. The only prefixes which are accepted are those which are explicitly permitted.
  • Egress BGP Policy to control all prefixes which are sent to the ASN’s peer and the Internet. The Egress BGP Policy would mirror the Ingress BGP Policy of their peer. The Egress BGP Policy would be set up as an explicitly deny filter. The only prefixes exported (egress) would those explicitly permitted in the policy.

Two core principles apply to today’s BGP Best Common Practices. First, the Ingress and Egress Policies on the peered session mirror each other. This requires coordination with the peer to ensure the filtering matches. Second, both the ingress and egress filters use an explicit deny policy. That means everything is filtered when there are no “permit” statements. Explicit deny (i.e. deny all) minimizes risk if there is something wrong with the prefix filter or an unexpected prefix injection happen on the Internet.

BGP Ingress Policy Checklist

INGRESS Policy allows BGP routes to come into your organization. BGP Ingress Policy is applied in stages with each stage with a different policy role. The stages depend on the vendor’s BGP implementation (or the BGP Open Source implementation). As a general rule of thumb, the following policy flow can be used as a guide. Through all these checks, remember that the policy would be a default deny, requiring an explicit permit.

1. Dynamic Maximum Prefix Sessions

It is not logical to have 20,000,000 prefixes received from the Internet. Max Prefix rule will look at the total number of prefixes received from the peer and set a threshold that will stop all further updates. The Operator would set this threshold as a “safeguard” for maximum prefix injection attacks or mistakes. Max Prefix Attack’s is where someone intentionally sends millions of prefixes into the Internet to cause instability. Max Prefix injection mistakes happen when there is a human, machine, or equipment error. Both will cause damage if there are no maximum prefix limits set on the ingress session.

2. Reject Bogon & RIR Minimum Prefixes

Bogon Prefixes are those reserved routes and unallocated prefixes which should not be advertised to the Internet. Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A “full Bogon” prefixes beyond the Regional Internet Registry “Minimal Allocatable Prefixes.” Filtering on the RIR Minimums prevent operators advertising /26, /27, /28, and other large IPv4 prefixes. This route filter has been called the “Net Police” approach and proved operationally beneficial.

3. Reject Bogon ASNs

There are ASNs which should never appear on the Internet. These Bogon ASNs have been and can be used for malicious activities. They can also appear from human error (connecting a lab network to the Internet by mistake.). NTT has provided a leadership example illustrating how BGP ASN filtering can be used to minimize risk on the Internet. NTT, AS 2914, will not accept route announcements from any eBGP neighbor which contains a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. NTT’s state reasoning behind this policy is twofold and helps illustrate the risk:

  • Private or Reserved ASNs have no place in the public DFZ. Barring these from the DFZ helps improve accountability and dampen accidental exposure of internal routing artifacts (minimizing human error).
  • All AS2914 devices support 4-byte ASNs. Any occurrence of “23456” in the DFZ is either a misconfiguration or software issue.

NTT (and others) are undertaking this effort to improve the quality of routing data as part of the global ecosystem. This should improve the security posture and provide additional certainty to those undertaking network troubleshooting (see The Harmful Consequences of Postel’s Maxim). Bogon ASNs are currently defined as follows:

0

# Reserved RFC7607

23456

# AS_TRANS RFC6793

64496-64511

# Reserved for use in docs and code RFC5398

64512-65534

# Reserved for Private Use RFC6996

65535

# Reserved RFC7300

65536-65551

# Reserved for use in docs and code RFC5398

65552-131071

# Reserved

4200000000-4294967294

# Reserved for Private Use RFC6996

4294967295

# Reserved RFC7300

A current overview of what are considered Bogon ASNs is maintained at NTT’s Routing Policies page. The IANA Autonomous System Number Registry is closely tracked and the NTT Bogon ASN definitions are updated accordingly. NTT encourage network operators to consider deploying similar policies. Configuration examples for various platforms can be found here:

  • http://as2914.net/bogon_asns/configuration_examples.txt
  • http://bgpfilterguide.nlnog.net/guides/bogon_asns/
  • BOGON ASNs MUST DIE (presentation by Job Snijders)

4. Reject IXP Prefixes

Internet Exchange Points (IXPs) will have IPv4/IPv6 prefixes for the IXP fabric. Many of these prefixes are specifically allocated to the IXPs as critical infrastructure. They should not appear in the global routing table. It is best practice to include all IXP prefixes for which you are connected in the ingress and egress route filters.

There are no standard templates for IXP Prefix filters. Each operator will have a list depending on the IXPs for which they have peered.

5. Reject Leakage with the Peer Locking Filter

Peer Locking is an emerging technique for projecting routing security one AS deeper into the Internet. Peer Locking uses a “secure what are within your zone of influence” approach. Operators who participate with Peer Locking enter into an agreement with their Peering partners who are directly connected (private connections or IXP connections).

The partner provides to pieces of information, their ASN which is to be protected (and connected) and any upstream operator who they authorize to route their ASN’s prefixes. As Job Snijders explains its operation in NTT (see below), Peering partner A is in “Peer Locking” with NTT. Peering Partner A states that prefixes with their ASN or via Peering Partner B are OK AS paths. If NTT sees their ASN from any other path, it would be seen as invalid and dropped. Peering Partner A has just expanded their “zone of prefix trust” one ASN deeper into NTT. Vice Versa, NTT has expanded their “zone of prefix trust” one ASN deeper into Peering Partner A.

Note, there is nothing wrong with NTT’s peering connections with Peer C, D, or E. In the illustration, if there is a human/machine mistake and a route is leaked out of Peer A, then NTT will contain that mistake with the PeerLock rules. In addition, if there is a BGP Prefix Hijack over Peers C or D, with Peer A’s AS path, that would also be “contained.”

This approach expands the zone for which an organization’s trust is now one ASN deeper into the organization. The power of Peerlock is in the numbers who participate. If Peer A peer locks with NTT, your areas of routing security are now two ASNs deep in both directions. Now if Peer A expand to Peer Z while NTT expands Peer Locking Peer B the result is a BGP prefix security depth has expanded 4 deep. This continues with Peer B expanding their Peer Locking to Peer M.

In essence, Peer Locking allows for Operators to take control over their BGP Prefix Hijacking and Route Leak Risk. The approach slowly expands their zone of prefix trust, adding resilience to their network interconnections.

NTT through Job Snijders has validated, documented, and deployed Peerlock with public material all Operators can use for their own Peerlock processes. The following are excellent resources to review to learn more about Peerlock. The good news for any Operator is that there are people who are willing to help with your organization’s Peerlock approach.

6. Match against the IRR Whitelist (only customers)

All customer connections must have an explicit permission of their prefixes. Notice that up to this point, all the REJECTS. This is the first place where prefixes are PERMITTED. The Internet community has posted a wide range of open source IRR Tools that would manage the BGP Peering sessions for all customers. There are Operators in the world who have scripts set up to deploy customer BGP sessions for thousands of BGP sessions. Many of the engineers in their Operator share their experience of how they are doing this automation, with many posting their scripts/code via Open Source Repositories.

7. Mark as Customer Route (or as peer route)

One a customer route is permitted, it would be marked with a BGP Community. This allows additional policies and services to apply to the customer prefixes. The new BGP Large Communities Attribute (RFC 8092) provides operators with more than enough BGP community space to create unique BGP Community policies. The first step is to mark all customers BGP prefixes with a community.

8. Scrub Internally Significant BGP Communities

There will be BGP Communities that are used inside the Operator’s network but are not authorized by the Customer. These could also come in from other Operators by mistake or abused by miscreants as part of BGP Prefix injection community attacks.

For example, NTT would not want some route to come in with 2914:666 that kicks in a Black Hole for that prefix (see a detailed list of NTT’s routing policies).

This step is also a place to remove excess BGP communities. BGP communities have a potential to be abused. Adding 20 BGP Communities to 10,000 de-aggregated prefixes will consume memory and CPU on routers. If something like this happens, the “removing internally significant BGP communities” filtering phase would be the perfect place to mitigate the incident.

9. Apply BGP Features

BGP Features are Local Pref, BGP Black Holes, and other functionality the Operator will provide their customers and peers. NTT provides a good example on their Routing Policies and Procedures Page.

BGP Egress Policy Checklist

EGRESS Policy is applied to BGP routes coming into your organization. Egress BGP Policy communicates how people get to your network. BGP Egress Policy is applied in stages with each stage with a different policy role. The stages depend on the vendor’s BGP implementation (or the BGP Open Source implementation). As a general rule of thumb, the following policy flow can be used as a guide. Through all these checks, remember that the policy would be a default deny, requiring an explicit permit.

1. Reject Bogon & RIR Minimum Prefixes

The EGRESS Bogon and RIR Minimum prefix filter is a safety net. The role is to protect the organization from “asking” for a DOS attack. The “DOS attack” would happen when a threat-actor gets into your network and finds a way to advertise Bogon and really large (more than /24) prefixes.

Bogon Prefixes are those reserved routes and unallocated prefixes which should not be advertised to the Internet. Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A “full Bogon” prefixes beyond the Regional Internet Registry “Minimal Allocatable Prefixes.” Filtering on the RIR Minimums prevent operators advertising /26, /27, /28, and other large IPv4 prefixes. This route filter has been called the “Net Police” approach and proved operationally beneficial.

2. Remove Private ASNs

Private Autonomous Systems Numbers (ASNs) are using inside network infrastructure. They are a productive tool for building network architectures. Private ASNs should never appear on the Internet. The Egress policy would remote private ASNs. Some vendors have special commands which when turned on will remote private ASNs. Others will require an explicit AS filter.

3. Reject “bad” security incident routes (they Murphy Filter)

BGP is used as a security tool within a large organization. BGP Remote Triggered Black Hole Routing (RTBH), Sinkholes, and BGP Shunts are all important tools to protect the network. The Best Practice is to place Egress filters on your BGP policy to ensure these actions do not leak out into the Internet.

The famous “Pakistan Hijacked YouTube” incident was an RTBH leaking to the Internet. The ASN in Pakistan did not have a “Reject “bad” security incident routes in their Egress Policy.

4. Accept/Permit Peer Routes (on customer sessions)

Egress BGP sessions to customers would include the routes from your peers. This sets up the shortest path between the customer and your peer (for example on a local Internet Exchange Point (IXP). If you did not do this, the customer would be routing out your transit connection, taking the longer and more expensive path.

Peer routes would NOT be permitted on the Egress connection to your upstream/transit connections. It is not advisable to provide your peers with free transit.

5. Accept/Permit Customer Routes (on every session)

Permit all customer routes on the Egress to your peers and your transit. These should be EXPLICIT PERMIT filters. That means you explicitly permitted specific prefixes from your customers and deny all others. That minimizes the risk of your customer’s leaking routes through your network, into the Internet, and causing your organization problems.

6. Do AS-Prepending (if requested & applicable)

Autonomous System prepending (AS-Prepending) is a tool used on the Internet to shape the routing decisions of other ASNs in remote parts of the Internet (more than two ASNs away). This is the stage where the AS-Prepending happens. It is placed in this order to ensure that the “policing” and “security” does not impact traffic engineering.

7. Scrub Internal BGP Communities

BGP Extended Communities allows Operators more flexibility. Sometimes Operator does not want these extended communities used for internal traffic engineering to be passed on to the entire Internet. This and other “internal use” BGP communities would be ‘scrubbed’ at this stage.

8. Set NEXT-HOP-SELF

Setting the BGP Next Hop to be the same peering router ensures that another router is not mistakenly used. This is a BCP for BGP peering configuration.

9. Normalize BGP MED

BGP Multi-Exit Discriminator (MED) is a traffic engineering tool to influence the path selection logic one ASN hop away (the adjacent peers). Many times these BGP MED settings will drift apart from router to router. This step is a reminder to review and normalize the BGP MED settings.


Recommendation: Require your peers to be compliant with the BGP BCPs.

Requiring organizations to be compliant to a standard is normal. It is done all over the world in multiple industries. Mutual compliance with industry standards is essential to healthy business relationships. It is not different in telecommunications and the Internet. If you are “BGP peered” with someone, you must expect that a mutual compliance is held between to organizations. That is the essence behind the Mutually Agreed Norms for Routing Security (MANRS).


Recommendation: Apply Ingress & Egress BGP Prefix, route, and community for all your BGP speaking interconnections.

Every transit, every peer, every exchange point, and every customer must have ingress (routes from the BGP peer) and egress (routes from you to your peer).


Recommendation: Deploy Bogon and RIR Minimal Allocated Prefixes

As mentioned in the INGRESS and EGRESS checklist, there are routes which should not appear on the Internet (Bogons). In additions, the Internet does not need really long prefixes (the /25s, 26s, 27s, etc in IPv4). These would be policed for all INGRESS routes and all EGRESS routes.

Bogon/RIR Minimally Allocated prefixes on the INGRESS protects your network and your customers from outside disruption. Doing a similar filter on your EGRESS will provide a safety net for normal human misconfiguration mistakes OR mischievous activity. “Mischievous activity” would be a threat-actor breaking into your customer’s BGP speaking router and then de-aggregating the IPv4 space.

Team CYMRU has been the custodian of a volunteer effort to maintain Bogon filter examples: http://www.team-cymru.com/bogon-reference.html They also provide a service that some Operators use which will use to protect against Bogon abuse.

What are today’s RIR Minimally Allocated Prefixes?

10 years ago each of the RIRs had a table for their address blocks. But, based on today’s Internet, many of the Operators have to advertise /24s on IPv4 to keep their services from being BGP hijacked.


Recommendation: Use Internet Route Registries (IRR) to register all BGP sessions to your ASN, require all your peers to use the same IRRs, and then script the configurations to update the ingress/egress prefix filtering.

Get Empowered with IRR Tools & Knowledge

NOCTION series to illustrate how routes can be pulled with a script from PeeringDB (a popular IRR) then used to generate configs.


Recommendation: Deploy Peerlock Light Minimize Risk (AS-Path Filtering)

Peerlock-lite is a deployed and proven safeguard for types of BGP prefix leaks and BGP hijacks. NTT has illustrated the deployability of the Peerlock approach. This is explicit AS-Path Filter based on the assumptions that a normal Operators will not sell transit to their upstream and major peers.

The Peerlock Lite policy rejects any prefixes you receive from your customers which contain a

$bignetwork ASN anywhere in the AS_PATH. Here is a Cisco IOS example:

ip as-path access-list 99 permit \

_(174|209|286|701|1239|1299 \

|2828|2914|3257|3320|3356 \

|3549|5511|6453|6461|6762 \

|7018|12956)_

route-map ebgp-customer-in deny 1

match as-path 99

A good video to gain context is Job Snijders (NTT) NANOG talk Everyday practical BGP filtering (video)(PDF).


Recommendation: Enforce “BGP Community Requirement” for any prefixes which are advertised.

Policy: All prefixes must have a minimum of one BGP community to enable the prefix to be shared with peers or customers. This means the BGP rule for the Community filter will be an “explicit deny” filter – denying all prefixes without BGP communities and only permitting prefixes with explicitly permitted BGP communities.


Recommendation: Use Maximum Prefix Filters on all BGP Sessions

Exploding BGP tables is one of the huge risks to Internet stability. We have had and will have router(s) which deaggregate, rapidly increasing the size of the BGP RIB. Increasing the size of the BGP RIP will have collateral impact on the routing stability, the convergence time, the CPU load on the router, and collateral impact on the forwarding FIB ASICs/FPGA/NPs which have limited table size.

One of the “hallway discussions” that happen in many NOGs is what would happen if several routers all disaggregated the Internet. While the whole Internet will go through an instability period, those networks which do not have MAX Prefix filters will be dramatically impacted.


Tools for BGP Peering, Analysis, & Monitoring

BGP Stream by BGPMON

BGP Stream is a free resource for receiving alerts about hijacks, leaks, and outages in the Border Gateway Protocol. BGP is both a backbone protocol to the Internet and the cause behind hundreds if not thousands of daily outages. Because of its antiquated design, and a lack of adoption of encryption or automatic verification methods, there is a lack of control to prevent these outages. In addition, regular BGP change notifications do not provide context around the nature of the change or the motivation behind them. As such, real-time monitoring for BGP changes and ASN announcement updates is a very important method to find indicators of a problem.

With BGP Stream, we use an automated process to cull the largest and most important outages, what type of outage it is, and which ASNs are involved and publish those updates for free to a Twitter feed and this site. It is important to us to provide this information free, in a real-time format, providing contextual information so network engineers and owners can respond to outages as quickly as possible.

BGP Stream

BGP Stream is an open-source software framework for live and historical BGP data analysis, supporting scientific research, operational monitoring, and post-event analysis. This is a project supported by the work at CAIDA.

tabi: BGP Hijack Detection Tool

Developed since 2011 for the needs of the French Internet Resilience Observatory, TaBi is a framework that eases the detection of BGP IP prefixes conflicts, and their classification into BGP hijacking events. The term prefix hijacking refers to an event when an AS, called a hijacking AS advertises illegitimately a prefix equal to or more specific to a prefix delegated to another AS, called the hijacked AS.

Usually, TaBi processes BGP messages that are archived in MRT files. Then, in order to use it, you will then need to install an MRT parser. Its companion is MaBo, but it is also compatible with CAIDA’s bgpreader. Internally, TaBi translates BGP messages into its own representation. Therefore, it is possible to implement new inputs depending on your needs.

Do Son work a TaBi introduction here – tabi: BGP Hijack Detection Tool


Presentations, Talks, BCP and Other Materials


Research Paper and Projects Exploring BGP Hijack Risk

The BGP Hijack Risk profile attracts a wide academic interest. This interest attracts government and private research funding to explore new anti-BGP Hijacking tools, techniques, and resiliency approaches. This work is always worth reading, tracking, and exploring to see apply to real-world operations.


News, Blogs, and References Articles about the Amazon Route 53 – MyEtherWallet Incident

It is always useful to read through the blogs, news, and articles about the incident. The following is a list. The object is to build a list “BGP Hijacking Risk Justifications.” These “Risk Justifications” are real and must be presented to your peers, your boss, other teams, your CxOs, and your Board of Directors. We should not have excuses “I didn’t know there was a BGP Hijacking/Stability risk” when the organization depends on telecommunications/Internet.