BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

Speakers: Cameron Morris

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=o6rI_fqvtDY

Overview

The Border Gateway Protocol (BGP) has been the foundational routing protocol for the internet for decades, yet its inherent security vulnerabilities have been a persistent concern since its inception. While significant strides have been made with the Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) to mitigate prefix hijacks, these defenses are not exhaustive. As RPKI adoption continues to grow—with over 42% of IPv4 address space protected by Route Origin Authorizations (ROAs) and an estimated 37% of Autonomous Systems (ASes) actively filtering invalid ROAs—attackers are inevitably shifting their focus to post-ROV attacks, those sophisticated threats that existing ROV mechanisms are unable to detect or prevent.

This talk introduces BGP-iSec, an innovative enhancement to the IETF standard BGPsec protocol, specifically engineered to provide substantially improved security against these emerging post-ROV threats. BGP-iSec targets three critical categories of attacks: route leaks, path manipulations, and attribute manipulations. The core motivation behind BGP-iSec is to overcome the two primary obstacles hindering BGPsec's widespread deployment: its high computational requirements and, more critically, its limited security benefits under partial adoption scenarios. By focusing on enhancing security benefits, particularly for early adopters, and ensuring interoperability with existing BGP standards, BGP-iSec aims to foster broader adoption of robust path-security mechanisms and secure the internet's routing infrastructure against increasingly sophisticated attacks.

Cameron Morris presents BGP-iSec as a crucial evolution in internet routing security, addressing the practical challenges of deploying secure BGP extensions. The work emphasizes a layered defense approach, incorporating mandatory transitive signatures and novel mechanisms for route leak prevention, all while striving for efficiency and robustness in real-world, partially adopted environments. This research is vital for network operators, security architects, and anyone concerned with the stability and integrity of global internet routing.

Background

▶ Watch: BGP security problem and BGP-iSec's goal (0:00)

The Border Gateway Protocol (BGP) has underpinned internet routing since 1989, but its trust-based design has made it susceptible to various misrouting incidents, most notably prefix/sub-prefix hijacks and route leaks. These vulnerabilities stem from BGP's original design, which prioritized flexibility and scalability over strong security guarantees.

The most prominent effort to secure BGP has been the development and deployment of Resource Public Key Infrastructure (RPKI), which allows legitimate holders of IP address space to cryptographically attest to the ASes authorized to originate routes for their prefixes through Route Origin Authorizations (ROAs). Route Origin Validation (ROV) then enables ASes to verify these ROAs, discarding routes with invalid origins. While RPKI and ROV have made significant progress in combating origin hijacks, their scope is limited. They do not protect against path manipulations beyond the origin, nor do they address route leaks, where an AS advertises routes to peers or providers that it should only advertise to customers. Furthermore, they do not protect against attribute manipulations, where attackers alter BGP attributes (other than the AS-path) to influence routing decisions.

The IETF's BGPsec protocol was designed to address path validation by requiring each AS to cryptographically sign its announcements, including the AS-path, next AS, and previous signatures. A receiving AS would then verify this chain of signatures. However, BGPsec faces two formidable obstacles to deployment. First, its high computational requirements for signing and verifying every BGP update are a significant burden, especially for large ASes with many peering sessions. Second, and more critically, BGPsec provides limited security benefits under partial adoption. Its signatures are non-transitive; if an adopting AS sends an announcement to a non-adopting neighbor, the signatures are dropped, and the route downgrades to regular BGP. This creates "BGPsec deployment islands," where verification only occurs within contiguous groups of adopting ASes, severely limiting its effectiveness in a fragmented internet. Crucially, even with full adoption, BGPsec does not inherently prevent route leaks or attribute manipulation.

BGP-iSec builds upon the foundation of BGPsec but fundamentally re-engineers its approach to signature propagation and introduces novel mechanisms. The routing model assumed for BGP-iSec, similar to many BGP security proposals, is valley-free routing, where ASes maintain customer-provider or peer-to-peer relationships, and benign ASes do not relay announcements from non-customer ASes to non-customer neighbors. Path selection policies, such as security-third (preferring fully adopting paths) or security-never (following the traditional Gao-Rexford model of customer-peer-provider preference, then shorter path), were considered, with security-never being recommended for its practicality and similar performance. Like BGPsec and ROV, BGP-iSec relies on the Known Adoption and Public Keys (KAPK) assumption, utilizing RPKI to distribute BGPsec router certificates that also signal BGP-iSec support. This background highlights the critical need for a protocol like BGP-iSec that can provide tangible security benefits even with partial adoption and address the full spectrum of post-ROV attacks.

Key Findings

▶ Watch: BGP-iSec's mandatory transitive signatures for integrity (6:00)

BGP-iSec introduces several pivotal advancements that significantly enhance the security of internet routing, particularly in scenarios of partial adoption, where existing solutions like BGPsec fall short. The key findings and contributions of this work are:

• Significant Security Improvement over BGPsec: BGP-iSec dramatically enhances routing security, especially during partial adoption. It outperforms BGPsec, offering substantial protection against interception rates even at low adoption levels (e.g., BGP-iSec at 10% adoption outperforms BGPsec at 99%).
• Comprehensive Protection Against Post-ROV Attacks: The protocol effectively prevents path manipulations, announcement manipulations, and route leaks, addressing critical gaps that BGPsec does not cover.
• Crucial Role of Mandatory Transitive Signatures: The introduction of mandatory, transitive signatures is fundamental to BGP-iSec's ability to provide security benefits in partial adoption environments, overcoming BGPsec's vulnerability to signature downgrades.
• Layered Defense Against Route Leaks: BGP-iSec implements a robust, multi-faceted defense against route leaks through three complementary mechanisms: Protected-OTC (integrity-protected Only-To-Customer attribute), UP attributes (Up-Permitted), and Providers-Cone Identification (ProConID). These layers provide robust protection against different attacker models, from global observers to full attackers.
• Comparable Efficiency at High Adoption: Despite its enhanced security, BGP-iSec achieves efficiency comparable to BGPsec at high adoption rates, especially when optimizations like "Best Path Only" are applied, making it operationally feasible.
• Interoperability and Standardization Leverage: BGP-iSec is designed to be fully interoperable with existing BGP and strategically reuses BGPsec mechanisms and RPKI where possible, streamlining potential standardization and deployment efforts.
• Formal Security Guarantees: The work includes formal security analysis, proving announcement integrity, guaranteeing no false positives under full deployment, and demonstrating prevention of route leaks under full deployment, as well as visible-leak prevention under partial deployment against a Man-in-the-Middle (MitM) adversary.
• Robustness to Real-World Conditions: BGP-iSec demonstrates robustness against reasonable levels of non-compliance, such as benign ASes dropping attributes, and resilience to extreme failures in the KAPK assumption (e.g., unknown adopters).

These findings collectively highlight BGP-iSec as a practical and powerful solution for advancing the security posture of the global internet routing infrastructure.

Technical Deep Dive

▶ Watch: Route leak defense: Protected-OTC attribute (10:00)

BGP-iSec builds upon the BGPsec framework but introduces fundamental architectural changes and novel mechanisms to achieve its enhanced security guarantees, particularly in the critical context of partial adoption. The core technical approaches revolve around mandatory transitive signatures and a layered defense against route leaks.

Mandatory Signatures for Announcement Integrity

A central innovation in BGP-iSec is the concept of Mandatory Signatures for Announcement Integrity. Unlike BGPsec, where signatures are non-transitive and dropped when an announcement crosses a boundary to a non-adopting AS, BGP-iSec ASes sign and verify every announcement originating from a BGP-iSec adopting origin. Crucially, these signatures are treated as transitive attributes. This means they are explicitly exported to both adopting and non-adopting neighbors.

This design choice directly addresses BGPsec's vulnerability to "downgrade attacks." In BGPsec, a non-adopting AS can strip signatures and manipulate the path or attributes undetected. With BGP-iSec's transitive signatures, even if an announcement traverses a non-adopting AS, subsequent adopting ASes can still verify the integrity of the portion of the path that passed through BGP-iSec adopting ASes. RPKI is used to identify BGP-iSec adopting ASes and distribute their public keys. An announcement from a BGP-iSec adopting origin is deemed invalid if it lacks a valid signature from all BGP-iSec adopting ASes in its path.

To manage the dynamic nature of BGP announcements, where attributes are modified as they are relayed, BGP-iSec protects specific integrity-protected attributes. These include the AS-path, the next-AS (similar to BGPsec), and, critically, the OTC (Only-To-Customer) and UP (Up-Permitted) attributes for route leak prevention. When an adopting AS X exports an announcement A, it adds its signature over a string TBSbyx(A). This string encodes all integrity-protected attributes and their values, as recovered by a revert(X,A) function. This cryptographic binding ensures that any manipulation of these protected attributes by an attacker will invalidate the signature, leading to detection and discard.

Additionally, BGP-iSec proposes an optional secure downgrade mechanism. This allows an AS, under temporary high computational load, to issue a hash-based downgrade ticket instead of a full signature. This mechanism aims to maintain network stability while preserving some level of integrity protection.

Defenses Against Route Leaks

BGPsec does not natively address route leaks. BGP-iSec introduces a three-pronged, complementary defense strategy:

1. Protected-OTC (Only-To-Customer): This mechanism leverages and strengthens the IETF's existing Only-To-Customer (OTC) transitive attribute. The OTC attribute signals that a route announcement should only be propagated downwards to customer ASes. In BGP-iSec, the OTC attribute is one of the integrity-protected attributes included in the signature. By signing the OTC attribute, BGP-iSec prevents a malicious AS from simply removing it to cause a route leak. If an attacker removes the signed OTC attribute, the signature becomes invalid. Alternatively, if a malicious AS attempts to leak the route by sending an OTC-marked announcement to a provider or peer, the receiving AS (if BGP-iSec adopting) would detect this policy violation and discard the announcement.

1. The UP Attributes (Up-Permitted): This defense primarily targets the Global Attacker model, where the attacker can observe all BGP announcements but cannot manipulate BGP-iSec specific attributes without invalidating signatures. When an adopting AS X exports an announcement to a provider (i.e., "up" the hierarchy), it adds two transitive attributes: UP-image (a hash of a randomly chosen UP-preimage) and the UP-preimage itself. The UP-image is signed as an integrity-protected attribute, but the UP-preimage is not signed and is removed when exporting to a customer or peer. If a receiving AS gets a signed UP-image but no correct UP-preimage, it is instructed to treat the announcement as "down-only." This makes it challenging for an attacker to remove an OTC attribute without also removing the signed UP-image (which would invalidate the signature) or guessing the UP-preimage (which is randomly chosen and ephemeral). This mechanism effectively creates a strong implicit "down-only" signal that is difficult for a global attacker to circumvent.

1. Providers-Cone Identification (ProConID): This is the strongest anti-leakage defense, designed to counter the Full Attacker model, where the attacker has full knowledge of all BGP-iSec attributes, including the UP-preimage. ProConID introduces a new RPKI object, the ProConID-list, which is signed and distributed by each BGP-iSec adopting AS. For an AS X, its ProConID-list contains the first BGP-iSec adopting AS along any upward path in its provider cone. An AS Y receiving an announcement A from an AS Xe (where Xe is an adopting AS) discards it if it's not ProConID-valid. This validity check involves specific rules related to provider/peer/customer relationships and verifying against the ProConID-list. For instance, if AS Y receives a route from its customer AS 666, and the route's origin or an upstream BGP-iSec AS (e.g., AS 1) is not in AS Y's ProConID-list, it indicates a leak. ProConID can be viewed as a more secure and robust variant of the IETF's ASPA (AS Path Attestation) proposal. The creation and maintenance of these lists are considered manageable, as provider cones are typically small (median size of 30 ASes in CAIDA topology), and the system can incorporate grace periods for new relationships.

These layered defenses, combined with mandatory transitive signatures, provide BGP-iSec with a comprehensive and robust framework to secure internet routing against a wide spectrum of post-ROV attacks, significantly improving upon the limitations of BGPsec.

Demo / Proof of Concept

▶ Watch: Route leak defense: UP Attributes for Global Attacker (12:00)

The talk describes extensive evaluation and simulation rather than a live demonstration or a standalone proof-of-concept tool. The BGP-iSec protocol was rigorously tested using custom extensions to the BGPy simulator. This simulator allowed researchers to model the behavior of BGP-iSec under various conditions and compare its performance against BGPsec and a baseline without path defense.

The simulations were conducted over the CAIDA serial 2 AS graph from September 2022, a realistic representation of the internet's AS topology. The evaluation specifically focused on post-ROV attacks, assuming a wide adoption of ROV and legitimate route origins. Attacker and origin ASes were uniformly chosen from multi-homed ASes within the simulated network. Different attacker strategies, such as "Aggressive" and "Shortest-Path Export-All (SP-EA)," were employed to assess BGP-iSec's resilience under diverse adversarial conditions.

The results, presented through various figures (Figure 7-14 in the original presentation), illustrate the effectiveness of BGP-iSec's mechanisms in reducing attacker interception rates, mitigating disconnections from Denial-of-Service (DoS) attacks, and analyzing computational and operational overhead. While not a runnable demo for end-users, the BGPy simulator extensions serve as a robust, scientific proof-of-concept, demonstrating the protocol's theoretical soundness and practical advantages through quantitative analysis.

Defensive Implications

▶ Watch: Route leak defense: Providers-Cone Identification (ProConID) (14:00)

BGP-iSec presents significant implications for network defenders, offering a path towards a more secure and resilient internet routing infrastructure. The core takeaway is that adopting BGP-iSec provides tangible, immediate security benefits, even in a world of partial deployment, which is a stark contrast to BGPsec's limited utility in such scenarios.

1. Prioritize BGP-iSec Adoption: Network operators should seriously consider BGP-iSec as the next logical step beyond RPKI/ROV. Its ability to provide robust protection against route leaks, path manipulations, and attribute manipulations—all post-ROV attack vectors—makes it a critical component for future routing security.
2. Focus on Transitive Signature Support: Defenders should advocate for and implement systems that support transitive BGP signatures. This fundamental change from BGPsec's non-transitive approach is what unlocks significant security gains for early adopters.
3. Implement Route Leak Defenses: The layered approach to route leak prevention (Protected-OTC, UP Attributes, ProConID) offers robust protection. Defenders should explore how to integrate these concepts into their routing policies and infrastructure. ProConID, in particular, requires ASes to manage and distribute their ProConID-lists via RPKI, implying a need for RPKI object management capabilities.
4. Prepare for Increased Verification Load: While BGP-iSec's computational overhead is comparable to BGPsec at high adoption, early adoption might see a temporary increase in signature verification. Network engineers should assess their router capabilities and potentially plan for hardware upgrades or optimization strategies (like "Best Path Only" verification) to handle the cryptographic load.
5. Leverage RPKI for BGP-iSec Support: The KAPK assumption means RPKI will be used not only for ROAs but also for distributing BGPsec router certificates that signal BGP-iSec support and ProConID-lists. Defenders need to ensure their RPKI infrastructure is robust and capable of handling these additional objects.
6. Understand Attacker Models: The research highlights different attacker models (Global, Full, MitM). Defenders should understand which BGP-iSec mechanisms protect against which threat, allowing for a more nuanced security posture. ProConID, for example, is crucial against the stronger Full Attacker model.
7. Advocate for Standardization: As BGP-iSec is a research proposal, defenders should engage with IETF and other standardization bodies to push for the adoption and refinement of these critical security mechanisms.
8. Monitor for Non-Compliance and KAPK Failures: The study shows BGP-iSec's robustness to benign attribute dropping and KAPK assumption violations. Nevertheless, defenders should implement monitoring tools to detect such issues and ensure their BGP-iSec deployment remains effective.

In essence, BGP-iSec offers a compelling roadmap for moving beyond the current limitations of BGP security. By understanding its mechanisms and preparing for its adoption, network defenders can proactively strengthen their networks against the evolving landscape of internet routing threats.

Key Takeaways

• BGP-iSec significantly enhances BGP security, particularly for partial adoption scenarios, where BGPsec offers limited practical benefits.
• It provides robust protection against post-ROV attacks, including route leaks, path manipulations, and attribute manipulations, which are not addressed by RPKI/ROV or BGPsec.
• The use of mandatory transitive signatures is crucial for BGP-iSec's effectiveness, ensuring integrity verification even when announcements traverse non-adopting ASes.
• A layered defense against route leaks, comprising Protected-OTC, UP attributes, and ProConID, offers comprehensive protection against various attacker models.
• BGP-iSec maintains comparable efficiency to BGPsec at high adoption rates, making it a viable and scalable solution for securing global internet routing.
• The protocol is designed for interoperability with existing BGP and reuses BGPsec mechanisms, facilitating potential standardization and deployment efforts.

About the Speaker(s)

Cameron Morris is the presenter of this work on BGP-iSec. The transcript does not provide additional details about his title or company, but his presentation demonstrates expertise in network security, particularly in the domain of Border Gateway Protocol and its cryptographic enhancements. His research focuses on improving the resilience and security of internet routing infrastructure against advanced threats.