Wednesday, February 12, 2014

[cert] Analyzing Routing Tables

Hi, Timur Snoke here with a description of maps I’ve developed that use Border Gateway Protocol routing tables to show the evolution of public-facing autonomous system numbers.
Organizations that route public internet protocol (IP) addresses receive autonomous system numbers (ASNs), which uniquely identify networks on the Internet. To coordinate traffic between ASNs, the Border Gateway Protocol (BGP) advertises available routing paths that network traffic could take to access other IP addresses. BGP tables select and advertise the best routes for network traffic. Consequently, BGP data often provide better insight into traffic ownership than the physical or the logical layer. This blog post describes maps that I have developed that use BGP routing tables to represent the evolution of public-facing ASNs.
Events of global interest can affect the Internet, and BGP can be used to track those effects. For example, if the citizens of a specific nation experienced problems accessing the Internet prior to an election, BGP routing tables for that country—including administrative ownership, organizational peering relationships, and data paths through physical connections—will demonstrate how Internet access could have been restricted.
A Matter of Trust
One vulnerability in the modern Internet occurs when individuals or entities broadcast (either intentionally or unintentionally) erroneous paths to access a particular IP address. This practice sometimes goes unchecked because the data reaches its intended destination after the suspicious detour.
Fortunately, several methods exist for attributing information about Internet entities. Regional Internet Registries (RIRs), for example, allocate IP addresses and assign ASNs to various organizations for different regions of the world. Across the globe, RIRs are broken down into five regions:
  • African Network Information Centre (AfriNIC) for Africa
  • American Registry for Internet Numbers (ARIN) for the United States, Canada, several parts of the Caribbean region, and Antarctica
  • Asia-Pacific Network Information Centre (APNIC) for Asia, Australia, New Zealand, and neighboring countries
  • Latin America and Caribbean Network Information Centre (LACNIC) for Latin America and parts of the Caribbean region
  • Réseaux IP Européens Network Coordination Centre (RIPE NCC) for Europe, Russia, the Middle East, and Central Asia
Sometimes an individual or organization advertises an IP address that they don’t actually own. These individuals or organizations do, however, have a relationship with the owner. Publicly available confirmation of this relationship may not exist, such as when a company is leasing capability through a service provider. This relationship can be discerned through routes that network traffic follows, as advertised through BGP routing tables.
A separate case involves an organization that owns IP space, which is located in a data center that they want to be highly available. As a result, the organizations will advertise the same IP space from multiple locations and the ASNs associated with them. For example, Google maintains vast IP space, but only two ASNs: one in the United States and one in Ireland. While Google advertises IP addresses through either ASN, network traffic is directed to the closest one.  
While looking for a strategy to identify relationships between a set of IP addresses that have raised alerts on perimeter security devices, I couldn’t assume access to domain name resolution. I found that BGP data can be used to attribute IP addresses and realized that BGP routing tables provide snapshots of the Internet and highlight the advertised IP address owner or the routing Start of Authority. I also discovered that BGP routing tables allow for the aggregation of specific IP addresses to the authoritative ASN that is claiming its control.
Using the Start of Authority and authoritative ASN data, I can conceptually attribute the IP address to the entity that actually controls it. This method is superior to the data in geolocation or WHOIS records, because those data are notional, not actual. Taking the method from concept to reality is then a matter of obtaining sufficient high-fidelity data. This is achieved by leveraging two services that have hundreds of BGP peering points that record views of the world:
Real-World Application
Analysis of BPG routing tables can reveal disruptions to an organization’s infrastructure as well as geopolitical information for an organization, country, or a city-state. While the Google example cited above shows a legitimate approach, sometimes network traffic is subverted to travel nefarious alternative paths to place the communications deliberately at risk.
Analysis of the routing topology for an organization or country can provide insights into how important a location is in terms of how many connections it has to the outside world, what its risks are, and whether it is setting up choke points that create risk or provide better control for its internal assets.
By examining the BGP routing tables for a country that tries to maintain tight controls on its population, we could identify choke points where censorship could be implemented. It’s important to note that BGP routing tables allow for speculation. Without a forensic investigation, we cannot verify if network traffic is manipulated. However, the BGP analysis provides a starting point to prioritize future investigations of this sort.
BGP routing tables can also provide information about resiliency or the ability of a service to recover from a disruption. Disruptions could include physical damage to infrastructure (e.g., cable cuts, power outages for supporting hardware) or logical damage to the routing tables (e.g., sending traffic to the wrong place and not providing alternate valid routes).
Top-level service providers strive for resiliency by connecting to multiple peers and using redundant data centers. The artifacts of this approach are readily visible with my BGP analysis. The BGP data also highlight fragile infrastructures. The consequences of a fault that is visible in the BGP advertisements are rather severe. During January 2011 when Egypt took itself off the Internet, hosts inside the country were cut off from the Internet. This was an internal disruption; we see from the data that non-Egyptian traffic that could no longer traverse cables in Egypt were not actually disrupted because of the diversity of alternate paths.
Another real-world example involves an analysis of BGP routing tables for Cuba. Internet speeds increased significantly in January after the country began routing traffic through an undersea fiber-optic cable that had been previously dormant.
As part of my research, through the RouteViews Project and RIPE RIS data, I am able to actively collect routing tables from over 600 peers and create a view of how the traffic can be routed on the Internet from one point to another. These relationships can identify who claims to own an IP address and show when advertisements are in disagreement.
Future Work
The following work will improve the accuracy and scope of situational awareness, either from public routing data or by using routing data to improve other data sources:
  • Validate the capabilities of the geo-location services and identify shortcomings.
  • Further stratify the routing design into verticals, such as civilian and/or public access, educational and/or research, and government agencies
  • Track routing changes between ASNs over time.
  • Identify administrative or organizational associations between ASNs.
We are also working with the University of Oregon Route Views project to set up a mirror website, which will provide an alternative storage location for this important data source.
We are also synthesizing daily IP to ASN associations for use with the SiLK tool suite. We plan publish those online. If anyone wants to know on a given day who was advertising what, we can facilitate that analysis directly without have to process the full routing table for the date in question. More information regarding usage will be covered in a future blog post, or you can contact our team with questions at netsa-contact@cert.org.

No comments:

Post a Comment