RPKI Defense Capability Simulation Method Based on Container Virtualization

Abstract

As the main inter-domain routing protocol in today’s internet, the Border Gateway Protocol (BGP) faces serious security risks during actual usage. Research on BGP malicious attack methods requires a realistic network environment, and evaluation methods based on physical networks often suffer from high costs and insufficient flexibility. Thus, we propose an efficient BGP simulated network deployment system based on a virtualization technology called the SOD–BGP. This system, combining cloud computing and virtualization technologies, creates a scalable, highly flexible basic network environment that allows for the automated simulation and evaluation of actual BGP prefix hijacking attack scenarios. A Resource Public Key Infrastructure (RPKI) simulation suite is introduced into the system, emulating a certificate issuance system, certificate storage, and a certificate synchronization verification mechanism, thus aligning the simulation environment with real-world usage scenarios. Finally, we propose a data collection and performance evaluation technique to evaluate BGP networks deploying RPKI under different attack scenarios and to explore the effectiveness of RPKI defense mechanisms at various deployment rates. A comparative analysis with other simulation techniques demonstrates that our approach achieves a balanced performance in terms of deployment speed, complexity, and RPKI integrity, providing a solid simulation technology foundation for large-scale BGP security defense strategies.

1. Introduction

The Border Gateway Protocol (BGP) is the core routing protocol of the internet. However, because of its early design and lack of inherent security mechanisms, the BGP currently faces numerous security threats. As the scale and complexity of the internet increase, the security issues of the BGP become more prominent [1]. Ensuring the security and detection within BGP networks has become a critical component of network intrusion detection [2,3,4] and situational awareness [5,6]. By implementing effective security defenses and detection measures [7,8], we can enhance the overall security of the internet and ensure the stable operation of the network.

To address the security concerns associated with the BGP, the Resource Public Key Infrastructure (RPKI) has been introduced as an enhancement mechanism [9,10,11,12]. The RPKI employs digital signatures to validate the authorization of IP address holders, ensuring the trustworthiness of the published routing information [11,12]. In recent years, there has been a notable increase in the number of autonomous systems (ASes) issuing Route Origin Authorizations (ROAs) for the IP prefixes they hold [11]. Consequently, to advance the research on the effectiveness of the RPKI defenses in BGP networks and enhance protocol security [9,13], it is imperative to construct a network scenario that can be deployed on a large scale and closely approximates real-world conditions, facilitating the security evaluation of BGP environments deployed with the RPKI.

Owing to the lack of a corresponding security protection mechanism, the BGP is often vulnerable to anomalous route announcement attacks [14,15,16,17]. Anomalous route announcement attacks against the BGP can be broadly categorized into two types: prefix hijacking and route leakage. According to the statistics presented in [18], prefix hijacking attacks are more likely to be maliciously induced than route leakage. Additionally, the frequency of prefix hijacking attacks is relatively high, and the RPKI has been currently shown to be effective in mitigating such attacks [16,17]. In recent years, relevant research has further explored defenses against BGP hijacking attacks [9,19,20,21,22]. Y. Gilad et al. [9] conducted a thorough investigation into the adoption of the RPKI and Route Origin Validation (ROV) and analyzed the impact of a partial adoption on BGP security. Therefore, exploring the defensive effect of the RPKI against prefix hijacking in BGP simulation network environments contributes to an in-depth investigation of BGP security and promotes the further development of the RPKI.

Simulations of BGP networks have garnered research attention. For simple network topologies, simulation tools such as GNS3 [23,24] can be utilized for deployment. However, these tools are designed primarily for emulating specific functionalities of various commercial routers, and they incur substantial hardware resource consumption that renders them impractical for large-scale simulation deployments. Furthermore, the deployment approach lacks flexibility, and the installation of different network environments is intricate, thus hindering the swift deployment of target topology networks. Consequently, researchers have increasingly turned to container virtualization technology for BGP network simulation [20,25], as it allows for a more efficient utilization of system resources and offers faster startup times. However, the simulation methods do not fully exploit the advantages of container virtualization technology, and the number of deployed virtual nodes remains relatively low. With respect to the RPKI simulation, only the ROV technique on the router side has been implemented thus far. Although the approach can accomplish basic simulation tasks, it is challenging to achieve a simulation environment that is closer to the real internet. Therefore, it is necessary to explore a new BGP network simulation method that offers large-scale implementation, high simulation fidelity, and flexible scalability.

To overcome the existing shortcomings in current containerization technology simulation methods, a network simulation method based on OpenStack and Docker containers, named the SOD–BGP, is proposed. The innovation of this method lies in the introduction of cloud computing platforms to achieve a large-scale network simulation across multiple hosts. This method also uses Docker container technology to achieve the comprehensive simulation of BGP networks and the RPKI while supporting simulation for both IPv4 and IPv6 scenarios. By employing our self-developed simulation node deployment and configuration technology, we have enabled flexible configurations and the automated loading of BGP malicious attack simulation scenarios. Additionally, our custom data collection strategy gathers data from both the control plane and the data plane, ensuring an accurate evaluation of the simulation results.

In summary, our main contributions are as follows:

• A simulation platform that integrates hardware resources and deploys virtual routing nodes on a large scale is proposed, which combines cloud computing technology and virtualized container technology.
• The complete framework simulation of the BGP and the RPKI is implemented on the proposed simulation platform, which includes the automatic configuration of dynamic routing protocols and the automatic release of RPKI certificate resources and encryption information.
• On the basis of malicious BGP prefix hijacking attacks, a data collection and performance evaluation technique is proposed to assess the defensive capability and effectiveness of the RPKI against malicious attacks from both the control and data planes in an experimental environment.

The remainder of this article is organized as follows. In Section 2, several related works are introduced. Section 3 describes the framework structure of the simulation method proposed in this article. Section 4 presents an exhaustive description of the framework and technical implementation. Section 5 introduces the data collection and analysis techniques for this experiment. Section 6 presents specific experiments and analyses to validate the simulation method. Finally, Section 7 summarizes the full text and describes future research.

2. Related Work

The relevant work on simulation approaches for BGP networks is outlined as follows:

In a work by A. Abaid et al. [23], GNS3 was utilized to simulate BGP networks, and on the basis of this, they analyzed BGP convergence via keepalive and hold timers. However, GNS3 has high hardware resource requirements, limiting its capacity to simulate only extremely small-scale network topologies and resulting in an inefficient router deployment. X. A. Dimitropoulos et al. [26] introduced an extensible BGP simulator, BGP++, constructed using the discrete event simulator NS-2 and Zebra. The simulator offers detailed and scalable BGP implementations, employing PDNS for distributed simulation across multiple workstations to achieve a large-scale simulation. Additionally, it provides a simulation toolset to read simple configuration files and expedite simulation configuration tasks. N. P. Lopes et al. [27] presented a highly efficient BGP simulator called FASTPLANE, which was designed primarily for BGP simulation in data centers. Compared to the latest technology of Batfish deployed in medium-sized data centers, FASTPLANE exhibited a performance that was two orders of magnitude faster. M. Brandt et al. [28] developed a new network simulator, BGPSIM, using C++ to evaluate BGP prefix hijacking attacks and countermeasures. The simulator exhibited excellent simulation performance, providing simulations within minutes. However, it gave up some advanced features of the BGP and lacked support for certain BGP extensions. While the above simulators are designed primarily for research purposes such as BGP route learning or network performance, they are insufficient in offering the necessary features and capabilities to simulate BGP security threat scenarios.

With the rapid development of container virtualization technology in recent years, there has been a growing trend toward BGP network simulations based on container virtualization. B. Alharbi et al. [25] used and extended the SEED Internet Emulator (SIE) simulator framework. The simulator is deployed through lightweight Docker containers and interconnects the containers according to topological relationships to create a BGP network simulation environment. Additionally, they introduced the RPKI into the simulation network and tested the impact on BGP network security under partial deployment conditions of the RPKI. However, the approach fails to achieve larger-scale simulation experiments, with a maximum simulation scale of 69 devices. For the SOD–BGP simulation method, we utilize Docker container technology as the virtualization technique to efficiently virtualize the computational resources of physical hosts. Additionally, by employing OpenStack, we distribute the simulation network across multiple computing nodes, thereby pooling physical resources to enable large-scale simulations.

P. Spadaccino et al. [20] used the KathBGPBuilder [29] tool, which is based on container technology, to investigate and successfully reproduce a BGP prefix hijacking incident that occurred in March 2022. Through the simulation and comprehensive analysis of the hijacking event, they validated that, in the scenario where the majority of ASes adopt RPKI policies, upstream entities can intercept prefix hijacking attacks and prevent a malicious prefix from propagating. This demonstrated that using RPKI security mechanisms can eliminate or mitigate the impact of prefix hijacking attacks. However, while the experiment included a validation of RPKI policies, it only simulated the affected ASes in the attack event, failing to reflect the effectiveness of the RPKI defense in a more complex network topology. Additionally, the analysis of the experimental results was relatively simple. In the SOD–BGP, we developed attack result collection technology to capture control plane changes across all routing nodes and to monitor the data plane reachability of nodes to the target address. By analyzing the collected results and generating visual graphs, we successfully presented large-scale simulation attack outcomes.

3. Architecture of a Cloud-Based BGP Simulation Platform for BGP Security Evaluation

Virtualization based on Docker containers offers advantages such as resource conservation, rapid startup, and easy maintenance and expansion. When coupled with cloud computing technology, it provides efficient and large-scale distributed management for virtualization. This combination equips us with powerful tools to create experimental environments and test scenarios, effectively meeting the research requirements for studying malicious attack behaviors in the BGP and the defense mechanisms of the RPKI. Considering this background, this paper leverages cloud computing platforms to design and implement a virtualization-based BGP network security simulation system. The aim is to provide a comprehensive and flexible simulation environment for the in-depth research and analysis of security issues in BGP networks. Additionally, the system can deploy components related to the RPKI, such as Certificate Authorities (CAs), RPKI repositories, and Relaying Parties (RPs), to support experiments associated with ROV.

The overall architecture of the platform is illustrated in Figure 1. In this architecture, we adopt a virtualized environment following the deployment model of the OpenStack cloud platform. Specifically, the system consists of one control node, one network node, and multiple compute nodes. Among them, the network node is responsible for creating, connecting, and controlling the virtual networks, whereas the compute nodes are used for creating virtual nodes and managing resources. The control node plays a guiding role in the entire system and is responsible for invoking the APIs of each node to achieve the construction and deployment of the target network topology.

On the basis of the above virtualized environment, the proposed BGP simulation network attack testing platform in this paper comprises simulation scenario management in Section 4.1, BGP network and RPKI component simulation in Section 4.2, BGP malicious attack scenario simulation in Section 4.3, and data collection with effect evaluation in Section 5. The details are as follows:

• Simulation scenario management: The main purpose of the SOD–BGP is to study the results of deploying defensive strategies to counter malicious attack scenarios under specific conditions. We define various elements used to create the simulation network, such as images, AS relationships, AS defense strategies, and configuration files for virtual routers, within a simulation scenario. Specifically, in a virtualized environment, the images serve as static forms of virtual nodes, where simulation nodes are composed of the images from virtual systems. By embedding a dynamic routing simulation module developed with FRRouting [30] into the base image, we achieve a functional transformation from regular virtual nodes to router virtual nodes. The generated routing images are synchronized to all the compute nodes under the control node’s scheduling to prevent the need to regenerate the images during the deployment, thus accelerating the deployment process. By adjusting the parameters of the simulation scenario, our simulation framework can achieve diverse simulation network deployments. The details are introduced in Section 4.1.
• BGP network and RPKI component simulation: In accordance with the simulated network topology of the BGP, deployment configuration files containing information about the network and node deployments are generated. The control node initially parses the AS connectivity relationships from the configuration files. Invoking the Neutron API of the network node creates a virtual network to interconnect the virtual nodes. The control node subsequently parses the information about the virtual nodes and uses the routing images generated in the simulation scenario management, along with the RPKI components, to instantiate virtual routing nodes, virtual CA nodes, and virtual RP nodes. Following the topology relationships, all the virtual nodes are interconnected through the virtual network, thus realizing the construction of the target simulated network scenario. The detailed simulation technology implementation is introduced in Section 4.2.
• BGP malicious attack scenario simulation: To simulate a BGP prefix hijacking attack, a random pair of routing nodes is selected on the basis of the routing protocol–simulated network as the foundational scenario. One of these nodes is designated the malicious attacker node, whereas the other node is the victim. Before initiating the attack, the root CA needs to issue ROAs corresponding to the IP address blocks held by the victim node. This ensures that the routing nodes employing the RPKI can perform ROV effectively. Upon selecting the attack type, the control node orchestrates the malicious attacker node to launch a specific attack against the IP prefix addresses held by the victim node, utilizing routing policies and route configurations. This step completes one cycle of a malicious attack. The detailed implementation method is introduced in Section 4.3.
• Data collection and effect evaluation: To verify the proper operation of the simulated malicious attacks and obtain the attack and defense results after deploying the RPKI, this paper introduces a client/server structured technology for collecting the attack results and evaluating their effectiveness. The data collection process begins by acquiring the routing tables of the virtual routing nodes, followed by monitoring the actual traffic path information of the nodes toward the simulated attack prefix addresses. After the data are filtered and processed, the results are initially stored locally on each node. Upon completion of the experimental operations, all the nodes synchronize their results with the server database. By thoroughly analyzing the collected data, extracting key information, and evaluating the attack effectiveness on the basis of metrics such as connection rates and hijack rates, this paper concludes by creating visualized charts to comprehensively present the experimental outcomes. The detailed technical implementation is introduced in Section 5.

4. The BGP Simulation Network Deployment

In this section, we provide a detailed introduction to our proposed BGP simulation framework to facilitate a large-scale simulation deployment. This simulation method relies on OpenStack Mitaka for a distributed deployment across different physical hosts and utilizes Docker container technology for virtual node simulation. This method reduces the performance overhead required for the simulation and enables the integration of the RPKI simulation to meet the simulation needs of combining the BGP large network topology with the RPKI.

4.1. Virtualization-Based BGP and RPKI Simulation Technology

To meet the construction requirements of the simulated target BGP network, this paper designs and implements virtual images for BGP network simulation and RPKI component simulation based on Docker container virtualization technology. This involves specific images such as BGP router images, RPKI server node images that integrate the CA and publication servers, and RP node images. Simulation image management encompasses processes such as building foundational images, creating Dockerfiles for specific images, compiling into Docker images, and synchronizing images. The specific process is illustrated in Figure 2.

In particular, the BGP router image is built upon the open-source routing software FRRouting 8.5.2 [30], which incorporates a self-developed router initialization configuration program, an automated route configuration loading script, and a data collection program at the application layer. This results in a virtual router image that features a dynamic routing protocol configuration, ROV execution, and experimental result collection.

The RPKI server-side node image is also based on the open-source software Krill 0.9.4. Exploiting Docker’s multi-stage image construction, the Krill binary program compiled during the build stage is implanted into the base image, thereby simplifying the Docker image and helping to speed up the creation of the simulation network. To achieve a fully functional RPKI implementation in the cloud platform simulation network, it is necessary to generate a root CA. The root CA, also known as a Trust Anchor (TA), is responsible for issuing self-signed certificates for the entire IP address space and its associated AS. To simplify the deployment process and enable the instance to provide services upon startup, a modified Krill configuration file is added to the image, deploying the publication server on the certificate authority as well. Additionally, to provide high-availability access for the RPs of many ASes, a reverse proxy software, NGINX 1.18.0, is included in the image. This setup allows the clients to access services without knowing how to directly access them while handling more concurrent requests to enhance simulation stability. As the root certificate is self-signed, the manual generation and addition of a root TLS certificate for issuing subordinate certificates are also needed.

The RP node image builds upon the base image by adding the open-source software Routinator 3000 0.12.1. During the image construction, it is necessary to install the root certificate generated by the server-side node in the RP. This enables the RP, upon deployment and startup, to automatically retrieve certificates from the publication server and verify the encrypted signatures of ROAs. All validated ROA entries are then pushed to the routers via the RTR protocol.

4.2. Distributed Simulation Environment Construction for BGP

The construction of the BGP malicious attack simulation scenario primarily involves the deployment of a large-scale network topology, which requires a flexible, accurate, and rapid construction approach. To address this, we designed an automated simulation network environment construction technique tailored for BGP virtual routers. The specific method is as follows:

• Generating the Topology Configuration File: The BGP is an inter-domain routing protocol operating between the ASes. Owing to the large scale of the AS-level network topology, it is necessary to generate a topology deployment file on the basis of the interconnection relationships between the AS nodes. To assess the security advantages of the BGP network environment by deploying additional security mechanisms under the condition of a partial RPKI deployment, the AS nodes need to be randomly selected for RPKI dependent software deployment on the basis of the given deployment percentage. The specific topology configuration information is presented in

  Table 1. Simulation network topology configuration information.

  Configuration Information	Attributes	Description
  Network configuration information	Name	Network’s name
  	Driver	Network type
  	Subnet	Specific subnet (1.0.0.0/8)
  Routing configuration information	Image	Image type
  	Name	Virtual routing node name
  	ASN	AS number of virtual router
  	IP Address	IP address of virtual router
  	Neighbors	Neighbors of virtual router
  	Networks	BGP announcement
  	ROV	Whether to execute ROV
  RP/CA configuration information	Image	Image Type
  	Name	Virtual node name
  	AS Num	Affiliated AS network
  	IP Address	Virtual node IP address
  	Gateway	Gateway IP address

  .
• Creating Virtual Networks: To ensure the IP address allocation for the nodes and data exchange between the nodes in the simulated network, upon parsing the network configuration information from the topology configuration file, the Neutron API of the network node is invoked to create a virtual network. Subnets are subsequently assigned to the virtual network, completing the establishment of the virtual network.
• Creating Virtual Nodes: On the basis of the routing configuration information in the topology configuration file, the virtual router nodes are created by loading the corresponding simulation images. These nodes are associated with their respective virtual networks and obtain network IP addresses. Additionally, the RP nodes belonging to the AS are created as needed. IP addresses are assigned to these nodes on the basis of the created virtual network, and their gateway addresses are modified to the IP addresses of the AS in the same network segment. This is done to achieve interconnection and communication between the RP and the CA server.

In the context of virtualized simulation experiments, manually establishing routing configurations on virtual nodes can be time-consuming and cumbersome once the target network topology is determined. Therefore, an automatic loading technique for configuration based on the BGP and the RPKI has been designed to achieve a virtual-level routing configuration. Specifically, on the basis of the routing configuration information in the topology configuration file, configuration details such as AS neighbor relationships and directly connected networks of the virtual router nodes are sent to the configuration program within the virtual router nodes. This process completes the automation of the BGP configuration. On the basis of the information about the RP nodes owned by the virtual router nodes, configuration details such as the RP node’s IP addresses and ROV routing policies are subsequently sent to all the virtual router nodes that require the RPKI configuration, which automates the RPKI configuration.

The construction process of the BGP and the RPKI simulation topology is shown in Figure 3.

4.3. Automated Loading Technique for Malicious BGP Attack Scenario

Malicious attack scenarios are the most crucial part of the BGP network simulation system. To simulate prefix hijacking events in real network environments as realistically as possible, we design a set of attack deployment strategies for the random selection of an attacker and a victim. Simultaneously, to quickly reproduce simulation experiment scenarios or verify the accuracy of multiple experimental results, the selected pair of attacker and victim, along with the topology deployment configuration file, is saved to the control node. The deployment configuration file is stored in standard JSON format, facilitating parsing and generation by the control program.

The logical topology of the BGP simulation network follows a three-layer structure [31], in which the first tier is the core AS and has access to the entire address space. The second-tier AS peers other ASes or provides transit services to other ASes. The third-tier AS, also referred to as the edge AS or stub AS, needs to peer with higher-tier ASes to connect to the internet. On the internet, most stub ASes are responsible for carrying traffic with source or destination addresses located within their own AS [17]. Therefore, the selected victim and attacker in the attack strategy are from stub ASes. Additionally, to be more consistent with actual incidents of malicious hijacking on the internet, we ensure that the shortest path taken by the attackers to the victims consists of no fewer than four hops, guaranteeing traversal through all the levels of the ASes.

Following the above rules for generating attacker and victim pairs, the CA must generate ROA information for the IP address prefixes held by the victims. In response to the issue that an excessively large number of ROAs needs to be generated in the simulation environment, this paper designs a batch ROA authorization management algorithm to achieve automated IP prefix authorization in the simulation network. The purpose of the batch ROA authorization management algorithm is to update all the ROA information to the corresponding virtual CA nodes for use by the virtual RP nodes. The pseudocode description of the specific algorithm is shown in Algorithm 1. The inputs of the algorithm include the operations to be performed, such as adding or deleting ROAs, and all the ROA information, where ROA information includes the IP prefix, ASN, and optionally the maximum prefix length. The output represents the result of the operation on the input ROA information. The algorithm first iterates through the ROA information and filters the maximum prefix length to ensure that the ROA information is in the correct format. If the ROA information is correct, it then performs the corresponding operations to publish or withdraw the ROA.

Algorithm 1 Batch ROA Management

Input: roas ← a list of ROA information, include IP prefix, length, max length, asn.         operation ← string for roa operation, include adding or deleting. Output: result ← roa operation result 1: for roa in roas do 2:        if exist maxlength then 3:                if maxlength < length then 4:                        result ← maxlength invalid 5:                else 6:                        update(roa, operation)    // perform corresponding operation 7:                        result ← successs 8:                end if 9:        end if 10: end for 11: return result

Once the BGP simulation network topology has converged, and all the ROAs are synchronized from the CA, the simulation program proceeds to initiate malicious attack scenarios on the BGP simulation network. For the simulation of prefix hijacking attacks, we control the attacking AS to simulate the hijacking of the victim’s legitimate IP prefix address via the normal BGP announcement method, thus completing a simulated prefix hijacking attack.

5. Data Collection and Effectiveness Evaluation Strategy for Simulation Result

To measure the security defense effect of the RPKI and conduct a security analysis under partially deployed conditions, this paper designs and implements a data acquisition and analysis technique as illustrated in Figure 4. This technique injects the data collection scripts into the targeted virtual nodes to perform accessibility tests at both the control plane and data plane levels, thereby measuring the route propagation that occurs after an attack. For the post attack results, we collect critical data in the following two aspects:

• Control Plane: The most obvious manifestation of prefix hijacking at the control level is the change in the virtual router routing table entries, which is also an intuitive demonstration of whether the RPKI works. Therefore, we use the data collection program in the virtual router to record the routing table entries at a certain time after the network topology reaches convergences. By searching for the hijacked prefixes and comparing them, we can access the ROV activation status and determine the security defense provided by the RPKI. To this end, the routing jitter Flap_i index is defined as the number of changes in the routing table’s best entries for AS_i during a single hijacking event.

  $$\mathrm{Fla}{\mathrm{p}}_{\mathrm{i}}=\mathrm{Entr}{\mathrm{y}}_{\mathrm{i}}^{\mathrm{t}2}-\mathrm{Entr}{\mathrm{y}}_{\mathrm{i}}^{\mathrm{t}1}\left(\mathrm{t}2>\mathrm{t}1\right)$$

  (1)

  In the above formula, ${\mathrm{Entry}}_{\mathrm{i}}^{\mathrm{t}}$ = {entry1, entry2, …, entryN} represents the set of detailed routing entries for AS_i at time t. Flap_i is the set difference in routing table entries between two moments, indicating the routing instability caused by the impact of prefix hijacking on the routing node AS_i. The Flap_i index allows us to assess the degree of routing instability in the simulated network topology. A higher index value suggests a greater malicious impact of the hijacking attack, resulting in a less stable network environment.
• Data Plane: According to the experimental results in [6], the RPKI also has an effect on the data plane. Although an AS deploying the RPKI will never use the BGP route announcements with an invalid ROV state, the AS may still forward announcements to an AS that does not adopt the RPKI because of more specific routing rules. Therefore, it is necessary to assess the impact of prefix hijacking on the data plane and uniformly quantify the results. The specific formula is described as follows:

  $$\mathrm{Result}\left(\mathrm{A}\right)=\left\{\begin{array}{c}{\mathrm{H}}_{\mathrm{i}}\left(\mathrm{S}\right)\\ {\mathrm{C}}_{\mathrm{i}}\left(\mathrm{S}\right)\\ {\mathrm{D}}_{\mathrm{i}}\left(\mathrm{S}\right)\end{array}\right.$$

  (2)

  Suppose that A is the set of all ASes, and that S is the set of ASes deploying the RPKI in the current network environment. H_i(S) means that when the AS deploying the RPKI is S, the data traffic of AS_i is hijacked by malicious attacks. C_i(S) indicates that AS_i is successfully connected to the prefix address held by the legitimate ASes, whereas D_i(S) means that AS_i is not connected to the prefix address announced by any AS. These three parameters can effectively measure the harm caused by prefix hijacking attacks on the BGP network when the RPKI is partially deployed. To assess the benefits of routers that have deployed the RPKI over undeployed ASes, we also define B_i(S) as follows:

  $${\mathrm{B}}_{\mathrm{i}}\left(\mathrm{S}\right)={\mathrm{C}}_{\mathrm{i}}\left(\mathrm{A}-\mathrm{S}\right)+{\mathrm{D}}_{\mathrm{i}}\left(\mathrm{A}-\mathrm{S}\right)$$

  (3)

Finally, the data collected based on the above technology are processed via a data analysis program to obtain experimental data and charts. In the following, the collection and analysis strategy proposed in this section is used to analyze and evaluate the results of the simulation experiments on BGP malicious attacks.

6. Experimental Verification and Analysis

To validate and evaluate the simulation technology proposed in this paper, experiments were designed for validation and analysis, including scenarios with the integration of virtual and real networks and large-scale network simulations. Compared with other methods, this approach is demonstrated to provide a simulation technology foundation for BGP malicious attack research.

6.1. Experimental Environment

The experiments in this paper were conducted via the Mitaka version of OpenStack. A total of four DELL R730 (Dell Technologies, Round Rock, TX, USA) servers were used in this experiment, all running CentOS 7. The specifications for the nodes are as follows: the control node has an Intel Xeon E5-2609 v4 1.70 GHz processor, 128 GB RAM, and 2 TB hard disk space; the network node has an Intel Xeon E5-2620 v4 2.10 GHz processor, 64 GB RAM, and 1 TB hard disk space; compute node 1 has an E5-2620 v4 2.10 GHz processor, 128 GB RAM, and 1 TB hard disk space; and compute node 2 has an E5-2609 v4 1.70 GHz processor, 64 GB RAM, and 2 TB hard disk space (Intel Corporation, Santa Clara, CA, USA). The Docker version on all compute nodes was 18.03.1-ce. All the physical nodes were interconnected through an Ethernet switch.

6.2. Virtual–Real Interconnected Scene Construction and Fidelity Testing

To verify whether the virtual routers can announce network prefixes and enforce the ROV and to test the fidelity of the simulation technology, we constructed a combined virtual–real simulation network test scenario on the basis of the above experimental environment. AS15169 represents a physical router connected to a host, simulating a router holding a legitimate network prefix. AS5 connects to the real internet through the ext network of OpenStack. The RPs connected to AS1 and AS7 fetch ROAs from the RPKI repository on the internet through AS5. Other BGP neighbor relationships are depicted in Figure 5.

Using AS15169 as the victim AS and its held prefix 8.8.8.0/24 as the target prefix, we designated AS6 as the malicious attack source in the simulation network. After normal network prefix announcements are made in the network, prefix hijacking and subprefix hijacking attacks were launched. We collected and analyzed the control plane and data plane attack results from the ASes other than the attacker and victim. The specific results are presented in

Table 2. Integrated virtual–real simulation experimental results.

Virtual Node	Title 2		Title 3
	Prefix Hijacking	Subprefix Hijacking	Prefix Hijacking	Subprefix Hijacking
AS 1	Connected	Connected	Connected	Connected
AS 2	Hijacked	Hijacked	Hijacked	Hijacked
AS 3	Connected	Hijacked	Connected	Hijacked
AS 4	Hijacked	Hijacked	Hijacked	Hijacked
AS 5	Hijacked	Hijacked	Hijacked	Hijacked
AS 7	Connected	Connected	Hijacked	Hijacked

.

The first column in the table shows the impact of the prefix hijacking and subprefix hijacking attacks on the BGP routers at the control plane level. For the ASes deploying the RPKI, both prefix hijacking and subprefix hijacking do not result in route flaps at the control plane. This aligns with the operating principles and defense mechanism of the RPKI. In contrast, for the ordinary ASes without any security defense strategies deployed, each attack leads to route flaps, affecting the stability of the control plane. The second column of data illustrates the impact of the BGP routers at the data plane for the two types of prefix hijacking attacks. In the case of prefix hijacking, AS3, although not deploying the RPKI, gains a higher priority for legitimate prefixes because of a shorter path to AS15169. This aligns with the working principles of the BGP. However, owing to the more specific route, AS3 is affected by the malicious attack in subprefix hijacking. Similar to the results on the control plane, AS1, which deploys the RPKI, can still withstand harm from two prefix hijacking attacks at the data plane level. However, AS7 experiences traffic being hijacked to AS6. This discrepancy between the routing table and the actual data flow in AS7 is mainly because AS7 cannot control how AS5 correctly routes the data to legitimate prefixes. Although AS7 identifies and discards illegal BGP announcements from the malicious AS, when the data are forwarded to AS5, AS5 still routes the data to AS4, resulting in data plane hijacking for AS7.

The above experimental results verify the effectiveness of the RPKI in preventing prefix hijacking attacks. Moreover, this simulation scenario supports connections with physical routers and the internet, facilitating standard data communication via the TCP/IP protocol. This shows the fidelity and flexibility of a BGP attack and defense simulation technology based on OpenStack. Additionally, the experimental results for AS7 illustrate the covert nature of BGP subprefix hijacking attacks. Focusing solely on the experimental results at the control plane would lead to a partial conclusion. By adding the collection of data plane attack results, we enhance the authenticity and effectiveness of the simulation technology.

6.3. Large-Scale Network Simulation Scenario Testing and Defense Results Analysis

The RPKI defense results in a large-scale BGP simulation network reflecting the authenticity of the simulation method, which is also a crucial indicator for distinguishing various simulation methods and holds significant enlightening significance for the deployment of the RPKI on the internet. To validate that our simulation method can support the requirements of creating large-scale BGP networks, it is necessary to establish simulation experimental scenarios for large-scale target networks. The simulation scenario involves a total of 905 virtual nodes, including 452 virtual routing nodes and 453 RPKI simulation nodes, distributed across two computing nodes. To ensure the high fidelity of the simulation test scenario, we extracted AS resources (IPv4 address blocks, IPv6 address blocks, and AS numbers) owned by a specific country and the connection relationships between the ASes on the basis of CAIDA AS Rank [32] and AS Relationships [33] topology datasets. Each AS was abstracted as a virtual routing node, allowing us to construct a complex simulation network topology on OpenStack computing nodes. Benefiting from Neutron’s isolated network, the simulation network does not impact the real network and enables cross-host communication for the virtual nodes through the network node. This verifies that, given sufficient physical server resources, deploying hundreds of virtual nodes on various physical hosts in a distributed manner can be achieved to compose a larger-scale simulation test scenario. The topology of the simulation network is illustrated in Figure 6. The cloud symbol represents a network we created, with the colors primarily used for visual distinction, while the host symbol represents a routing node or a RP node. The lines indicate that the nodes are directly connected through a specific network.

On the basis of the target network topology information, the experimental results of the prefix hijacking and subprefix hijacking attacks conducted according to the simulation test designed in this paper are shown in Figure 7. The results measure the security protection obtained by the BGP simulation network using an ROV from both the data and control planes and demonstrate the additional benefits of deploying the RPKI for nondeployed ASes. Figure 7a shows the relationship between the overall hijacking rate at the data plane and the RPKI deployment rate. For ordinary prefix hijacking, the best path selection in the BGP mainly depends on the length of the AS path. Therefore, in the absence of RPKI deployment (RPKI deployment rate = 0), some ASes have a higher priority for legitimate prefix holders and are not affected by malicious attacks. In contrast, for subprefix hijacking, on the basis of the longest prefix forwarding rule, all the routing nodes are maliciously hijacked in the absence of any security mechanisms. The experimental results indicate that the RPKI has a better defense against prefix hijacking attacks when the RPKI deployment rate is relatively low. As the deployment rate increases, both in the control and data planes, the simulation network shows a significant improvement in defense against malicious attacks. However, as shown in Figure 7c, the RPKI also has certain ancillary benefits for other nondeployed ASes. Nevertheless, the improvement in security for nondeployed ASes is limited, and there is no significant difference in the defense against different types of attacks.

The above experimental results indicate that the RPKI can achieve a high level of defense even at relatively low deployment rates. As the deployment rate increases, the improvement in defense efficiency gradually becomes less pronounced. However, from a network security perspective, deploying the RPKI to counteract hijacking attacks is still recommended. Additionally, simulated tests of attack behaviors have demonstrated the effectiveness of conducting RPKI defense capability testing in virtualized scenarios. This provides sufficient data support for subsequent security assessments.

6.4. Comparative Analysis with Other Simulation Methods

To demonstrate the advantages of the simulation network deployment method used in this paper in the field of BGP routing protocol security research, we conducted a performance comparison with other popular simulation methods. This evaluation assessed the performance and deployment differences of various simulation technologies in the context of BGP routing protocol security research.

A performance comparison with other simulation methods was conducted on a virtual machine with a four-core CPU and 8 GB of memory. This virtual machine was exclusively configured with the environment and software required for the simulation methods. We performed the comparison by creating a single network node with an identical network configuration. The startup time in the comparison results starts from reading the configuration file to create the virtual node until the node is available. A lower startup time for the virtual nodes indicates a faster deployment speed for the simulation method. The CPU and memory resource utilization represents the average resource usage within the first 10 s after the creation of the simulation nodes. The comparative results are illustrated in Figure 8.

Figure 8a shows that the simulation method presented in this paper has a significant advantage in terms of startup time. This implies the faster completion of the target topology creation, which is especially beneficial for large-scale simulation deployments. For the NS3-Dce mode, the first run requires the compilation of the script to create the network, and the displayed startup time is after the compilation is completed. If it is the first run, the startup time would be longer than the time shown in the figure. In terms of CPU resource consumption, as shown in Figure 8b, our proposed method is similar to SEED and results in lower CPU resource consumption. In the single-server deployment scenario, where CPU resources are typically more constrained, a lower resource consumption is advantageous for the large-scale node simulations. Regarding memory consumption, as illustrated in Figure 8c, our method addresses how routers perform ROV verification but incurs additional memory resource consumption. However, this memory overhead still has a significant advantage over the GNS3 and NS3-Dce mode. For a comprehensive simulation of RPKI functionality, such additional overhead is deemed worthwhile.

Combining the above comparisons of the simulation methods, we evaluate the various methods in terms of four aspects: virtual node simulation scale, completeness of the RPKI framework, deployment speed, and deployment difficulty. The evaluation and analysis results for each method are presented in

Table 3. Performance comparison of various simulation methods.

Simulation Method	Single Physical Server Simulation Scale	Support Complete Deployment of RPKI	Deployment Speed	Deployment Difficulty
This article	Approximately 350 nodes	Yes	Fast	Medium
GNS3 [24]	Approximately 25 nodes	No	Slow	Hard
NS3 [34]	Approximately 1000 nodes	No	Fast	Hard
SEED [25]	Approximately 70 nodes	No	Fast	Medium

.

Although GNS3’s Cisco IOS method, which is based on Dynamips 0.2.17, can achieve the authenticity of the simulated network, it has poor support for the RPKI and cannot implement RPKI deployment alone. In addition, the GNS3 method requires extremely high server resources and cannot complete the creation of large-scale simulation networks. The discrete event network simulation method based on NS3 can achieve a large-scale network simulation on a single server, but its performance in simulation authenticity is poor. The simulation of the RPKI is insufficient and its implementation is difficult. Both the method proposed in [16] and the method presented in this paper are based on Docker containers. However, the approach in [16] cannot achieve the deployment of simulated networks across physical hosts, failing to fully leverage the advantages of distributed deployment. Consequently, its deployment scale is far inferior to that of the method proposed in this paper.

Considering the comprehensive comparison above, the cloud-based BGP simulation network attack and defense technology proposed in this paper exhibits a good balance in terms of the single physical node scale, comprehensive RPKI support, deployment speed, and difficulty. This approach provides a solid foundation for in-depth research on the relationship between the security of the BGP networks and the RPKI defense mechanisms. Additionally, it offers an effective and feasible solution for the application of simulation technology in the context of the RPKI.

7. Conclusions

Virtualization technology is currently a mainstream technology for network simulation. This paper integrates a cloud platform and virtualization technology to implement BGP network topology simulation and simulates RPKI facilities similar to those in the actual internet as much as possible in the simulated network. On the basis of these experiments, the advantages and security threats of prefix hijacking were tested under different RPKI deployment rates for the BGP routers. This paper presents an effective method for constructing and simulating BGP network topologies, facilitating the validation and comparison of the various BGP security mechanisms to support research on the security of BGP networks. As future work, we first aim to enhance the deployment scale of the nodes on a single server and to further develop our automated deployment technology to achieve different levels of prefix aggregation. Following this, the next step will focus on utilizing this methodological framework to investigate and design simulations of other BGP malicious attacks and their corresponding defense strategies.