-
Notifications
You must be signed in to change notification settings - Fork 7
Scenario
The Scenario class (implemented here) is the first class that takes part within the simulation framework. We've now gone over everything with the simulation engine, and know how to set routing policies, seed announcements, and propagate them throughout the internet.
The Scenario class helps us do that SimulationEngine setup. It defines in a simulation how we select the victim and attacker. It also defines how we select which ASes will adopt a certain routing policy. Afterwards the scenario classes uses this information to determine which announcements should be seeded into the SimulationEngine. We will go over all of this functionality now.
These two functions select the attackers and the victims. In generally, they take as input an ASNGroup from the scenario_config (discussed later), and choose the attacker and victim based on this ASNGroup. By default, the attackers and victims are chosen from stubs or multihomed ASes, since these ASes are most often the content providers rather than transit ASes. For obvious reasons, victims can not also be attackers. Additionally, when we are comparing two scenarios (ex: What happens if the internet deploys ROV instead of BGP?) we want the scenarios to be comparable. That's why the previous attackers and victims are also passed to these functions. If the previous attackers or victims are set, we will use the same attackers or victims from the last scenario. It's also important to note that the number of attackers or victims is simply a parameter, thus allowing for multiple attackers.
This returns a frozenset of ASNs that are going to adopt the policy set in the ScenarioConfig's AdoptPolicyCls. It uses as input the previous scenario, as well as the percent adoption, and a hardcoded_asn_cls_dict defined in the scenario_config (discussed later). This is the set that is fed into the SimulationEngine and determines the routing policy at each AS.
If the previous scenario is set, to ensure that we remain comparable to past scenarios, the same adopting ASNs that are used in that scenario will be used for the next scenario. Otherwise, we randomly select the adopting ASNs to deploy the AdoptPolicyCls as defined by the scenario_config (discussed later).
The random selection of ASNs for the adopting routing policy is defined in the get_randomized_adopting_asns function. From a high level, first, we remove any ASes that are preset, such as the asns in the hardcoded_asn_cls_dict, the attackers, and the victims. Then, for each adopting subcategory, we randomly select the adopting ASes according to the adopt policy percentage. By default the adopting subcategories are stubs_and_multihomed, input_clique, and etc (the remaining ASes). For example, if the percent_adopt is 50%, the reason we don't just randomly select half of all ASes to adopt is because different categories of ASes have different weights for adoption, and this drastically increases the variance of the simulations. For example, an input_clique ASes (defined by CAIDA, aka tier-1 AS) is highly connected, and if an input_clique AS adopts a security policy the impact will be __ far greater __ than if a stub AS adopts the security policy. so if the percent_adopt was 50%, then 50% of the input clique ASes would adopt, 50% of the stubs and multihomed ASes would adopt, and 50% of the etc (the rest of the internet) would adopt.
The Scenario class also defines which announcements get chosen for the attacker and victim. In most cases, this is the only function that needs to be overridden for your Scenario. You can see an example of a subprefix hijack scenario here