Announcement

Home

Tutorial

Announcement

We've mentioned Announcements several times. Announcements are the messages that ASes send to one another. This class can be seen here. The nice feature about this Announcement class is that it is a frozen dataclass. That means it is both immutable, and hashable, so you'll never have to worry about a reference being changed unexpectedly.

There are a few attributes defined in the Announcement class:

• Prefix

ASes own specific prefixes that they announce to the internet. Each prefix is simply an IP address with certain bits omitted. Each IP address is just a 32 bit address often represented in this format: 1.2.3.4, where each number can go up to 255. For example, let's take an IPv4 prefix, 1.2.0.0/16. What this prefix is saying is that The first 16 bits are set (1.2), and the prefix contains the entire range of the last 16 bits. So IP addresses from 1.2.0.0 all the way up to 1.2.255.255 would be contained within this prefix. So if AS 1 announces 1.2.0.0/16, the world would know that if they wanted to route to any IP address from 1.2.0.0 to 1.2.255.255, they would route to AS 1. In BGPy, these are merely strings since the ipaddress's ip_network can be quite costly to copy around.

• next_hop_asn

Equivalent to the next_hop in a normal BGP announcement, this is used to determine where the announcement should route packets to on the data plane. In a normal BGP announcement this is an IP address, however, for our simulations, this is an ASN for simplicity. We used to simply use the last ASN in the AS Path, but certain attacks actually use this attribute, so now we do data-plane traceback (described later) using this attribute.

• as_path

The AS Path is just a list of the ASNs that the announcement has visited. Counter-intuitively, the AS path actually goes from right to left. That is to say that the origin (The AS that first announced the announcement) is on the farthest right side. Then, as the announcement traverses the internet, ASes will __ prepend __ themselves to the AS Path

• timestamp

Currently this is just a number representing the timestamp, and we do not use it. We kept it around because there have been some papers that have shown that some ASes actually prefer older announcements as a tiebreaking mechanism. We never got around to doing these simulations to determine if this was true or not, but if it was, it would definitely change the outcomes of simulations for things like prefix hijacks. Hopefully one day we get to this, but until then, victims have a default timestamp of 0, while attackers have a default timestamp of 1.

• seed_asn

This attribute is where the announcement is going to be seeded in the AS Graph. We can't assume that the announcement will be seeded at the origin, because some attacks involve path manipulation. For example, in an origin hijack, an AS 666 may lie and claim to be next to the legitimate origin AS 777 of an announcement, and thus the AS Path would be (666, 777) but the seed_asn would be 666.

• recv_relationship

This sets the Relationship enum to clarify whether the announcement was from a peer, customer, provider, or origin

• withdraw

If an announcement is withdrawing a previous one, this attribute will be set. It's unlikely that users will ever set this attribute, and is handled by underlying functions within the BGPPolicy class. If you are using only the BGPSimplePolicy class, this will always be False.

• Properties

There are also various useful properties of the Announcement class, such as origin, invalid_by_roa, etc.

Copying announcements

It's important that when copying the Announcement class, you use the built in copy function of the Announcement. That way, you can change the underlying data structure of the announcement, and the simulations will not break. For example, certain use cases have changed the announcements to not even be a dataclass, and since the Announcement.copy was used everywhere, the announcement was still compatible with the simulations.

While this may seem like a good use case for an abstract class, we don't implement an abstract class for the Announcement since it significantly slows down the simulations. Copying of announcements is the number 1 bottleneck, so doing anything that makes that slower (such as inheriting from an abstract class) tends to make this quite a bit slower.

Policy specific fields

There are several attributes of the announcement that are meant to support specific policies. These are detailed below. It's important to note that the size of the Announcement class does significantly affect simulation times. While we've built the announcement class for maximum policy support, if you're only simulating a specific policy it is much faster to use an announcement class that has less attributes (which can be passed in to the scenario_config, explained later).

It may also seem like it would make more sense to simply include these optional attributes as a dictionary, but unfortunately this data structure significantly slows down simulation propagation

• roa_valid_length and roa_origin

These two attributes are for ROAs. These were explained in the Background section of this tutorial so I won't re-explain them here. Normally ROA validity (both by length and by origin) are determined by something like routinator which can validate a prefix for an announcement based on ROAs. However, doing this at each AS would be slow, and for our simulations, is not necessary. We can simply determine this attribute once per announcement, upon the announcement's initialization, since it will never change. In theory you could just implement something that would validate ROAs once, but again, that's overly complex for no reason. We can simply set the attribute upon announcement initialization.

• bgpsec_as_path, bgpsec_next_asn

These are two attributes used by the bgpsec policy. The bgpsec_as_path represents the valid, signed AS path. the bgpsec_next_asn is the next asn attribute that gets set by the bgpsec AS. Paradoxically named, the bgpsec_next_asn is the ASN that the announcement is being sent to, which is the opposite direction of next_hop_asn attribute or next_hop of normal BGP announcements

• only_to_customers

OnlyToCustomers attribute as defined in RFC9234 and used in the OnlyToCustomersPolicy. BGP-iSec uses this as a "signed" OTC attribute. We only keep one attribute here for speed rather than keeping a list.

• rovpp_blackhole

ROV++ blackhole attribute, used by the ROV++ policies

Next: Simulation Engine