Introduction

The Border Gateway Protocol (BGP) is a crucial routing protocol that enables communication between Autonomous Systems (AS) on the internet. It plays a vital role in ensuring the efficient and reliable delivery of data packets across the global network. However, like any system, BGP is susceptible to errors and misconfigurations, leading to potential issues with network connectivity. One such mistake that can have severe consequences is advertising the wrong prefix of another AS in BGP. In this blog, we will explore the implications of this error and the steps that can be taken to prevent it.

Understanding Prefixes and AS in BGP

Before delving into the consequences, let’s briefly recap the basics of BGP. An Autonomous System (AS) is a collection of IP address prefixes under a single administrative domain. Each prefix represents a unique range of IP addresses associated with a particular network. BGP is used by AS routers to exchange routing information, such as the available prefixes and the best paths to reach them.

The Misconfiguration: Advertising the Wrong Prefix

In a typical BGP environment, each AS advertises its prefixes to its neighboring ASes. This information is then propagated throughout the internet, ensuring that routers can make informed decisions about the most efficient paths for data transmission. However, sometimes, due to misconfigurations or human error, an AS may inadvertently advertise a prefix that belongs to another AS. This mistake can have significant ramifications.

Consequences of Advertising the Wrong Prefix

  • Blackholing Traffic: When an AS advertises the wrong prefix, traffic destined for that prefix may get directed towards the incorrect AS. If the incorrect AS is not equipped to handle the incoming traffic, it may drop it, causing a “blackhole.” This results in data loss and potential service disruptions for affected networks.

  • Traffic Hijacking: Another serious consequence is traffic hijacking, where an AS illegitimately announces a prefix that it does not own. This allows the malicious AS to reroute traffic intended for the legitimate owner of the prefix to their own network. This type of attack can lead to data interception, manipulation, or unauthorized access to sensitive information.

  • Routing Instabilities: Misconfigured BGP advertisements can cause routing instabilities and suboptimal path selections across the internet. The wrong prefix announcement can create loops, leading to excessive use of network resources and adversely affecting overall network performance.

  • Reputation Damage: If an AS becomes known for advertising incorrect prefixes or engaging in malicious activities, its reputation may suffer. This can lead to other ASes refusing to establish BGP peering relationships, isolating the offending AS and further exacerbating the impact of the misconfiguration.

Tips to improve BGP security

  1. Make BGP Authentication Great Again!
    Implement BGP authentication using MD5 or the more secure TCP-AO (TCP Authentication Option). By authenticating BGP sessions between neighboring routers, we ensure that only authorized peers can exchange routing information. Honestly, MD5 is not a great algorithm to protect your packets with these days, due to weaknesses in the algorithm. It is however better than sending them in clear text. This prevents unauthorized entities from injecting false routes into our network.

  2. BGP Monopoly: Embrace Route Origin Validation!
    Route Origin Validation is a critical security measure that helps ensure the legitimacy of received routing updates. By cross-verifying route announcements with the registered origin AS (Autonomous System) for that prefix, we can detect and mitigate BGP hijacks caused by incorrect or malicious route advertisements.

  3. Peer Politeness Policy
    Implement prefix filtering policies to control the routes accepted from peers. By explicitly defining the prefixes we expect to receive from specific Autonomous Systems, we reduce the risk of accepting invalid or unauthorized routes. If the upstream ISPs of Pakistan Telecom had employed proper prefix filters, the leakage of YouTube’s prefixes in 2008 would have been prevented. It is the responsibility of ISPs to ensure that their customers only advertise legitimate prefixes that belong to them.The lack of filters is often attributed to the perceived overhead and effort required for implementation and maintenance. However, this process can be automated by retrieving data from routing registries and regularly updating it, making it a manageable task. Presently, there are ISPs already adopting this approach and readily available tools to facilitate the implementation.

  4. Regular Audits: BGP Got Talent!
    Perform regular audits of your BGP routing table to identify and remove stale routes and inconsistent advertisements. Routinely review the peering relationships with your transit providers and peers to ensure that only valid routes are propagated.

  5. It’s Raining BGP Flowspec!
    BGP Flowspec (BGP Flow Specification) is a powerful mechanism that enables the distribution of traffic filtering rules across BGP routers. By applying fine-grained traffic filtering based on specific attributes such as source IP, destination port, and protocol, we can mitigate the impact of DDoS attacks and other malicious activities.

  6. Cryptography time
    RPKI, which stands for Resource Public Key Infrastructure, plays a crucial role in enhancing the security and reliability of the Border Gateway Protocol (BGP). RPKI is a system that allows Internet Service Providers (ISPs) and network operators to digitally verify the legitimacy of IP address prefixes advertised in BGP updates. It utilizes cryptographic certificates to bind IP address blocks to the rightful holders, preventing route hijacks and address spoofing. By validating the origin of BGP announcements through RPKI, network administrators can effectively protect their routing infrastructure from malicious attacks and accidental misconfigurations. RPKI adoption promotes a more trustworthy and resilient routing system, mitigating the risks associated with prefix hijacking and bolstering the overall stability of the global Internet routing architecture.

  7. NO to Default Routes (Unless You Mean It)!
    Minimize the use of default routes from external peers unless it is a deliberate part of your network design. Relying on default routes from untrusted sources increases the risk of accepting unauthorized and potentially harmful routing information.

  8. Encourage BGP Communities
    BGP Communities allow network operators to tag routes with community values, facilitating the implementation of specific policies throughout the network. Encourage the use of BGP communities among your peers to signal intentions for route propagation and filtering.

  9. Fortify BGP Speaker
    To safeguard the BGP speaker, it is essential to implement protective measures like control plane policing (CoPP). CoPP restricts access to TCP port 179, which is the well-known port used by BGP, allowing only configured BGP neighbors to send packets to it. Additionally, protection against ICMP floods and other control plane attacks is necessary. In cases where control plane filters are not supported, data plane filters can be an alternative, but they require more intricate configuration.

  10. Keep the data updated
    Updating your data in routing registries like ARIN and RIPE is crucial as some ISPs employ prefix filtering based on this information. Failing to input your routes and routing policy might result in your routes not being advertised. Ensure your data remains current and include new prefixes you intend to advertise while removing any that no longer belong to you.

Conclusion

Securing BGP is a collaborative effort that involves all stakeholders within the internet community. By implementing these professional tips, we can fortify our networks against BGP hijacking attempts and maintain a reliable, secure, and efficient global routing system. Let us collectively strive to create a safer digital landscape for the benefit of all users and organizations on the internet.


Reference Credits:

  • RFC 7454 by Jerome Durand, Ivan Pepelnjak and Gert Doering
  • Daniel Dib’s blog