Protecting your Business, Customers, & the Internet from BGP Route Hijacking Chaos?
(DRAFT – Version 0.11)
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 security risk. We have BGP security risk where the BGP session is attacked. We have BGP Security risk where the BGP route is hijacked and rerouted to another part of the Internet. We have BGP security risk where someone has made a routing mistake and disrupt routing across the Internet. We have BGP security risk where someone adds and removes your prefixes rapidly, causing a BGP DOS attack as ASNs “dampen” your prefix. Then we have the nasty BGP security risk where miscreants “de-aggregate” the Internet from multiple locations rapidly increasing the size of the global Internet route table and consuming all router memory and CPU. Luckily, all of these BGP security threats can be minimized through the tools we have deployed in the past along with the new Resource Public Key Infrastructure (RPKI) validation resources.
In this guide, we will cover all of these risks, using the BGP Hijack as our cornerstone. BGP Hijacking has a direct impact on mobile operators, telecom companies, governments, and enterprises all over the world. Deploying tools to minimize the BGP Hijacking risk will also minimize the risk to other BGP Security threats.
What is 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).
Table of Contents for BGP Security Practices
The following table is a link to a whole series of BGP Hijacking & Routing Mistakes Risk Reduction Principles. This includes guides, news articles, configurations guides, tools, services, and other capabilities.
- Principle: BGP Hijacking Risk Reduction is a Layered Solution. Reducing the BGP Hijacking risk reduction is a layered solution. Organizations cannot jump into RPKI BGP Security if they have not established the basics for BGP Security. It must be remembered that projecting against BGP Hijacks is not a “one tool” approach. All the BGP Security techniques work together.
- Recommendation: BGP Ingress & Egress Filtering BCPs. The core BGP Security recommendation is for all BGP Ingress & Egress Filtering to follow BCPs. These BGP Best Common Practices (BCPs) are not confidential. Your peers would be open to share what they do and help you deploy better policies. It is recommended that you inspect your network’s practices and procedures. Review the BCP gaps, areas of improvement, then build an action plan to iterate improvements.
- Recommendation: Grasp the risk from BGP Hijacking. It is really important that ever organization grasp the risk from BGP Hijacking. The CIO, CISO, Security Professional, Network Engineers, and all others in the organization must understand that the BGP Hijacking Threat to their organization is Real.
- Recommendation: Use Internet Route Registries (IRR). 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.
- Recommendation: Deploy Peerlock. Operators who deploy Peerlock will many of the of the route leaking and BGP Hijacking risk. Peer-Lock is an optimized AS-Path Filtering technique.
- Recommendation: All prefixes will have one BGP Community. We have learned in the community that it is safer to have all prefixes with one BGP Community. That means a BGP community will be required for the route to get advertised to a peer.
- Recommendation: Use Maximum Prefix Filters on all BGP Sessions. Maximum Prefix Filters are often overlooked in BGP configurations. Don’t overlook BGP Maximum Prefix Filters. They can save your network in a route table explosion crisis.
- Tools for BGP Peering, Analysis, Troubleshooting & Monitoring. Tools to troubleshoot routing issues, monitor for BGP Hijacking, and alert when there are major routing issues are critical for any organization who connects to the Internet.
- BGP Hijack Presentations, Talks, & Tutorials. Looking for what people are saying about BGP Security, BGP Hijacking, and BGP Routing Risk? This is an archive of presentation materials.
- BGP Hijacking Risks Research Papers and Projects. This is a large archive of papers and materials around the space for BGP Security.
- BGP Hijacking News, Blogs, and References Articles. Every BGP Hijacking news article is another opportunity for an organization to push for action within their organization.
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: 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: 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.