Contributed Article By: TWABULLDOGG (originally posted to the real OmniNerd)

In the U.S. – China Economic and Security Review Commission annual report, the United States Congress called into question motives behind an Internet based event on April 8, 2010. During the incident mentioned in the report, a Chinese ISP hijacked approximately 15% of all Internet traffic for 18 minutes and intentionally rerouted traffic for malicious purposes.¹

With all of the publicity from the Google vs. China incidents, I was surprised this was not widely publicized when it initially happened since it once again involved China and such a large portion of the Internet.² An accusation like this, especially contained within an official government report before Congress, is fairly significant. Whenever I read a government based technical analysis I wonder about its accuracy, so I want to investigate the claims made in the report.

How Networking Works

Before getting into what happened, an understanding of the protocols behind how the Internet operates is required.

There are two types of routing protocols: Interior Gateway Protocols (IGPs) and Exterior Gateway Protocols (EGPs). The purpose of an IGP is to inform every router how to forward packets from any source to any destination, allowing the packets to traverse the shortest path through the network. An IGP is typically used within a network controlled by a single organization, such as within the network of a major university or Internet Service Provider (ISP). The IGP’s goal is for every router to possess a complete and consistent picture of the network. Achieving this consistent state throughout the network is known as convergence.

Based on the purpose of an IGP, what is the shortest path and how is it calculated? That depends on the IGP you select. Open Shortest Path First (OSPF) implemented on a Cisco router uses 100,000,000 / Interface Bandwidth as the metric, or cost of reaching a network through a given path.³ The Routing Information Protocol (RIP) only uses the number of routers traversed, or hop count.⁴ Since the components of IGPs vary, each IGP may believe a different path is ‘best’ according to its combination of metrics and best path algorithm.

To achieve convergence, each router participating in the IGP tends to share all available information with every other router regarding the current status. Each router attempts to fully inform its neighbors by sending routing advertisements. Once again, depending on the IGP selected these advertisements take different formats. Basic OSPF has six standard formats for sharing link, node, and network information with every router so every router has the same map of the logical network. Based on this common map, each router will select an identical path to reach each known destination using Dijkstra’s Algorithm.⁵ IGPs that operate by sharing information regarding every node and link, then forming a common picture in the same manner as OSPF, are known as Link State Protocols.

The other type of IGP, known as Distance Vector, has each router operate only based upon what it hears from its directly connected neighbors using a distributed version of the Bellman-Ford Algorithm.⁶ Since each router relies on its directly connected neighbors for information, each router will send everything it knows to every neighbor. The neighbors will respond with everything they know; if the original router learns something new, like a new destination network, it will decide the best path to the destination and inform all of its neighbors regarding the new destination. Each router will decide the best path based on what it knows, then respond to the original router and their own neighbors. This exchange of information continues until the network converges.

IGPs are used in virtually every network on the Internet. However, the issue with IGPs is scalability. Sharing so much information is vital to an IGP’s operation, but at some point the large amount of information could overwhelm the resources within a router. In a large network, a single outage could seriously disrupt all traffic while the routers reconverge since router to router traffic is processed before normal user traffic. In Distance Vector networks, an advertisement may bounce around the network for several minutes before the routers achieve convergence. For Link State protocols, the best path selection algorithm is CPU intensive and if the network is large or network destinations are being added/removed frequently, it will quickly cause degraded performance.

BGP and the Internet

There are numerous issues as to why the Internet is not run entirely via IGPs. To list a few:

• Scalability issues mentioned in the previous section.
• IGPs cannot talk directly to each other since they have different metrics, advertisement formats, and path selection algorithms.
• Internet Service Providers (ISP) consider internal network topologies and routing information proprietary. IGPs share too much information.

The Border Gateway Protocol (BGP) is the de facto Internet standard for interdomain routing. BGP was first standardized in Request For Comments (RFC) 1105 in 1989.⁷ After many updates to support additional features and functionality (such as IPv6, Multi-protocol Label Switching (MPLS), MPLS VPNs, etc.), the current standard for BGP version 4 is RFC 4271.⁸ It continues to be updated with additional features and functionality.

To break the Internet into a scalable architecture, consisting of competing and non-cooperative ISPs who guard their information as much as possible, BGP functions differently from IGPs. On the Internet, each domain or Autonomous System (AS) (defined as a “network of routers under the control of a single administrative entity”)⁸ must have its own Autonomous System Number (ASN). An ASN is a 16 bit number which is unique and assigned to a single domain. If a router is participating in BGP, it can only belong to one ASN; so each router within a domain belongs to the same ASN. For instance, MCI uses ASN 701 for all of their routers. All of the ISPs are interconnected to some degree, providing multiple paths to reach each destination, generating a large and unorganized spiderweb that forms the backbone of the Internet (visualized in the following map of the known inter-connectivity between all ASNs in 2009).

Map of the Internet Core available from – http://www.caida.org/research/topology/as_core_network/pics/ascore-ipv4-ipv6.200903_poster_1250x850.png

Unlike IGPs, BGP does not provide a large amount of information to its neighbors. At a minimum, BGP provides Network Layer Reachability Information (NLRI), which includes the Network, Subnet Mask (the combination of network and subnet mask is referred to as a prefix), plus the Next Hop, origin, and the Autonomous System Path to form an advertisement.⁸ There are many optional attributes (similar to metrics in IGPs), but I will only focus on the minimum required attributes. The most important, for the purposes of this discussion, is the AS Path. When a destination network is first placed into BGP, or originated by an ASN and sent to another domain, the router attaches its ASN to the advertisement. As the advertisement is passed from AS to AS, each one attaches its own ASN to the front of the AS Path. This provides a method to avoid routing loops and is key to the Path Selection Process of BGP.

Since BGP does not advertise as much information as IGPs, it does not have a best path algorithm like IGP does in order to select the ‘best’ path. Instead, BGP uses a Path Selection Process to choose which path to use for forwarding. For the purposes of this article, I am only listing the first two steps:

1. Highest local-preference
2. Path with shortest AS path

The local-preference is unique to BGP and is not required to be advertised outside a domain. This administratively configured number (Cisco’s default value is 100) is used to provide preferential treatment to one path over another, even if the second path has a shorter AS path.⁹

Based on the Path Selection Process, a router will receive all the advertisements from its neighbors, make its decision and then inform its peers of what it believes to be the best path to a given destination. Once again, this may happen several times before the BGP network converges.¹⁰

BGP in Reality

In an effort to be concise, I am leaving out a large amount of information regarding BGP (as well as IGPs), how it operates, how it treats external neighbors (neighbors with a different ASN) differently from internal neighbors (same ASN), path selection steps, attributes, and attribute manipulation (such as local_pref). While detail on these components is critical to fully understanding BGP, they are only marginally relevant to this particular discussion unless taken at a much deeper level. However, many of them cannot be verified or analyzed without inside knowledge of ISP operations, information which is, of course, considered proprietary.

One additional concept that must be understood is that no matter what make or model of router is used, or what protocol is implemented, every router will select the most specific path it knows to reach a destination. This means that when a router looks at two network advertisements, both of which are potential paths to a destination IP, the router will select the path with the most bits in the subnet mask or Classless Inter-Domain Routing (CIDR). I am not going to attempt to explain subnet masking in this article or CIDR since only a basic understanding of what a subnet mask is will be enough for this discussion. As an example, say a router has 10.0.0.0/8 and 10.1.1.0/24 in its routing table and is trying to determine which one to follow to reach the IP 10.1.1.1. Because 10.1.1.0/24 is more specific, the CIDR (/X at the end) is larger, the router will select that path.

Also, because BGP allows administrators the ability to override the AS Path length, it allows a great deal of flexibility in both preferring one path over another and which advertisement to send to neighbors. A network administrator may choose to advertise certain networks to one neighbor and not to another, thereby filtering the advertisements to selected neighbors. They may also choose to advertise a less optimal path to a neighbor. Filtering on inbound advertisements can also occur, which allows a network administrator to ignore some of what a neighbor advertises. While this may seem inefficient at first, it allows network administrators to control how traffic enters and leaves their networks. Various considerations drive this filtering; sometimes its is for optimal use of bandwidth or it may be to manage path decisions across links where ISPs charge on a per usage basis (e.g. prefer the cheaper ISP). Routing decisions, at the human level, are not always made with regards to optimizing the network.

So What Allegedly Happened?

According to the Report to Congress (pg 244, 252 in Adobe):¹

For about 18 minutes on April 8, 2010, China Telecom advertised erroneous network traffic routes that instructed U.S. and other foreign Internet traffic to travel through Chinese servers.* Other servers around the world quickly adopted these paths, routing all traffic to about 15 percent of the Internet’s destinations through servers located in China. This incident affected traffic to and from U.S. government (.gov) and military (.mil) sites, including those for the Senate, the army, the navy, the marine corps, the air force, the office of secretary of Defense, the National Aeronautics and Space Administration, the Department of Commerce, the National Oceanic and Atmospheric Administration, and many others. Certain commercial websites were also affected, such as those for Dell, Yahoo!, Microsoft, and IBM.

Although the Commission has no way to determine what, if anything, Chinese telecommunications firms did to the hijacked data, incidents of this nature could have a number of serious implications. This level of access could enable surveillance of specific users or sites. "It could disrupt a data transaction and prevent a user from establishing a connection with a site. It could even allow a diversion of data to somewhere that the user did not intend (for example, to a 'spoofed' site). Arbor Networks Chief Security Officer Danny McPherson has explained that the volume of affected data here could have been intended to conceal one targeted attack. Perhaps most disconcertingly, as a result of the diffusion of Internet security certification authorities," control over diverted data could possibly allow a telecommunications firm to compromise the integrity of supposedly secure encrypted sessions.

* This type of attack is referred to alternatively as 'IP [Internet Protocol] hijacking' or 'prefix hijacking'. Note that the erroneous data appear to have originated at a smaller Internet Service Provider, IDC China Telecommunication, and were subsequently propagated by China Telecom.

* There are unconfirmed reports that Chinese Internet Service Providers have engaged in such activities. See, for example, Oiwan Lam, 'China: ISP level Gmail phishing,' Global Voices Online, August 11, 2010. http://advocacy.globalvoicesonline.org/2010/08/11/china-isp-level-gmailphishing/.

* For a brief explanation of the vulnerabilities associated with the current Internet certificate authority regime, see Danny O’Brien, 'The Internet’s Secret Back Door,' Slate, August 27, 2010. http://www.slate.com/id/2265204/. For a detailed description that relates specifically to China, see Seth Schoen, 'Behind the Padlock Icon: Certificate Authorities’ Mysterious Role in Internet Security,' in China Rights Forum no. 2 (2010), 'China’s Internet': Staking Digital Ground (New York: Human Rights in China). http://www.hrichina.org/public/contents/article?revisionlid=175292&itemlid=175290.

* This is referred to as a 'man in the middle' attack. Dmitri Alperovitch (vice president, Threat Research, McAfee, Inc.), briefing to Commission staff, August 25, 2010.

Reading this excerpt, especially the portion about routing all traffic for 15% of the Internet’s destinations to China made me question the validity and accuracy of the statements in the report. To me, the report appears to claim everything to/from the hijacked networks, no matter where the traffic originated or was destined, would route through China. That is a very bold statement; one which I do not believe could be supported by facts. I do not disagree that using routing to redirect traffic is possible and could be used for all kinds of malicious purposes. However, I wanted to investigate the claims made by the congressional report.

The original NY Times Article from April 8th, quoted in the report is vague on details and does not go into the harshness of the Congressional Report.¹¹ However, another NY Times article, released after the Congressional Report indicated, “there was also speculation that the rerouting might have been a test of a cyberweapon that could be used to disrupt the Internet during a crisis or a war”, escalating the accusations to an entirely new level.¹²

Is this a new cyberweapon by China? Well, that really depends on what they did with the hijacked networks (if it was intentional) if the incident was malicious. However, this type of ‘attack’ is nothing new. Misconfiguration of BGP, or the advertisement of networks by more than one ASN, is not an uncommon occurrence.¹³ In fact, at least one company uses these miconfigurations as the basis for its business model.¹⁴ BGPMON will monitor BGP advertisements to inform the owner of a network when another ASN attempts to claim ownership of the original network.

In reality, the only reason this incident garnered so much recognition was due to the number of hijacked prefixes, and likely because someone in China caused it. Despite all of the finger pointing, this is exactly how BGP is supposed to behave. In the previous section, there was no mention of security because BGP has essentially no security when it comes to verifying the source of an advertisement. Over the past 10+ years several solutions were proposed to resolve this security flaw: Secure-BGP, Secure Origin BGP and most recently RPKI.^{15, 16, 17} These solutions all provide a method of using Public Key Infrastructure (PKI) and digital certificates to validate the origin and/or path of an advertisement. While good in theory, the potential solutions are not without their own issues. The big one is financial cost.¹⁸ ISPs would be the ones forced to upgrade all of their equipment to support this initiative, but how would it benefit them? As commercial companies, if there is little to no benefit (potential to increase profit), why would they implement a potentially costly solution? The answer is they won’t. This scenario was acted out during S-BGP’s original push when ISPs failed to adopt and implement S-BGP. It will likely occur once again when RPKI fails to be deployed.

Analysis Methodology

In order to see what happened on April 8th, I would need the ability to look into the BGP routing tables of the Internet. Luckily, the University of Oregon Route Views Project provides a huge repository of BGP data dating back to 1997.¹⁹ The Route Views Project peers with ISPs around the world in order to get a view of BGP for historical and academic purposes. Every two hours, the routing table of each router is logged in binary MRT format and stored online for anyone to download and analyze.²⁰ In addition to each full routing table, the routers are constantly performing logging based on BGP Update messages, which are backed up every 15 minutes. So whenever something in the Internet changes and the Route Views routers are able to see the change, they store the message sent by BGP which states, “this is what changed.” Since Route Views routers are peered with ISP routers worldwide, they are able to view the Internet from multiple perspectives.

A word of caution for anyone interested in performing their own research. Each of these files are stored in the bzip format and appear small, but the unzipped, raw binary RIB files are approximately 900 megabytes each. If you were to run the unzipped file through an MRT interpreter and make them into a readable text file, they explode up to about 2.5 gigabytes apiece.

I did not want to write an MRT parser to make the binary files readable, so I used the zebra-dump-parser tool.²¹ This allowed me to interpret the raw files and view them in a readable format. Such large text files are cumbersome to work with, so I wrote my own perl scripts to sort through the output of zebra for me. I piped the output from zebra-dump-parser into my scripts which retrieved the relevant information. If the reader wants to replicate my tests, I used OS X and the latest version of Cygwin for running all the scripts with the command string (without any quotes):

bunzip2 -c 'Rib or Update file.bz2' | ./zebra-dump-parser.pl | ./bgp.pl 'option' > 'Text file.txt'

The first step in determining the extent of the incident was to establish a baseline. The RIB table files from Route Views provided this for me! Every two hours I was provided with the owner, or originator of every prefix on the Internet according to Route Views. To establish ownership, I parsed all twelve RIB files and created a list stating which ASN originated each of the ~325,000 prefixes. If there were any conflicts, such as two different ASNs claiming ownership of a prefix, the script recorded both ASNs which claimed ownership so I could see the conflict.

Using the baselines, I should be able to use the update files to find out if any ASNs claimed ownership of new networks they did not normally claim! The big question was where to start? The update files are created every fifteen minutes, so if there are a lot of updates during two update periods (either consecutively or with a small file in between) it could indicate when the dastardly deed occurred. The following image displays an abbreviated list of the update files.

There are two periods (0030 and 1115) that have a large number of updates, but no coinciding change within 18 minutes (the length of the ‘attack’). That leaves two likely pairs: 0800 & 0830 or 1545 & 1600. I chose to start with the 1545 & 1600 pair.

Since the changes occurred across a RIB dump boundary, I should be able to get a good idea of what changed so I selected the 1545/1600 pair. I opened up the results of my RIB dump for 1400 and 1600 in emacs and performed a quick ediff-buffers between the two. For non-*nix users, emacs is a text editor and the ediff will take two text files and compare them for differences.

The quick ediff comparison would prove extremely useful by showing:

1. If a prefix had two ASNs claiming ownership only to have one drop off (now ALL the Internet would route to the remaining ASN).
2. If a prefix used to have one ASN claiming ownership but now had two.
3. If a prefix had one but it changed to a different ASN entirely.
4. Whether longer matches for prefixes were advertised to claim ownership outright (remember where I said a router will always select the best match?).

My ediff resulted in 7409 differences between the two consecutive RIB tables. This number is a little misleading since ediff will count consecutive lines as a single difference. For instance, I found nine consecutive prefixes where ASN 23724 was added as an originator, but ediff only counted this as one difference. My number of differences would be below the actual number using ediff, but something very useful was noticeable right away. Of the networks that had a different originator (most had two now instead of just one), ASN 23724 was the new originator (a Chinese ISP ASN), so I knew I was on the right track. There were a few prefixes that now had a new owner entirely; those networks were typically Chinese networks that were originated by other Chinese ASNs (for example 17799, 4809 and 17633) but now belonged to 23724. Of special note is ASN 4134. It appears to have the most occurrences of ASN 23724 originating more specific prefixes in order to control traffic. However, 4134 is the ChinaNet Backbone ASN, which means that the Chinese were essentially hijacking themselves.

I wanted more specifics regarding the differences, so I added the option to compare two RIB Dump files to my scripts. The result identified every network that either did not exist in the 1400 RIB tables or had new/additional/fewer owners in the 1600 RIB table. The script result showed 21,282 prefixes had new owners. Since ASN 23724 is identified as our culprit ASN, I did a grep -c on the new results to find out exactly how many new prefixes ASN 23724 claimed ownership of, which resulted in 20,957 results. This is a fairly large number of routes and seems like a good list to start with.

Using the list of hijacked prefixes, I searched through the update file from 1545 using my scripts to retrieve every update that included one of the hijacked prefixes. The first update with ASN 23724 claiming ownership occurred at 15:54:19. The last update regarding the hijacking occurred at 16:15:08 in the 1615 update file. This appears to have lasted longer than 18 minutes, but when you consider the size of the Internet, convergence in BGP can take several minutes to occur. Depending on an ASN’s location in the Internet it could potentially see the attack start and end at different times and last longer than the 18 minutes mentioned in the report so I was not overly concerned with the three minute time difference.

With an established timeline for the event, I now needed to examine the extent to which this occurred. According to what was stated in the Annual Report, I should see “15 percent of the Internet’s destinations” being routed through a new owner, Chinese ASN 23724.

Since we went over how Routing and BGP work, it should easy to see that if one ASN advertises a network, 100% of the traffic for that network will be directed towards the originating ASN. What may not be so obvious, and likely caused some of the erroneous claims I am investigating in the Congressional report, is the Internet is so enormous that when two ASNs advertise the exact same network/CIDR the Internet will essentially split in two! When I say this, I mean that based on the best path selection process of BGP, one portion of the Internet will choose one originating source and the other portion will choose the second originating source. My goal in all of this was to determine where this dividing line exists. How prevalent was this hijacking? The annual report makes it appear there was no dividing line, that everything for these networks was rerouted, but that is nearly impossible as long as the real owners are still advertising their networks.

To determine if I had all of the hijacked prefixes, I took the hijacked prefix list form earlier (the one with 20,957 entries) based on the 1600 RIB dump. From this, I added to my script the ability to take in the list of prefixes and add to the list based off the update files. I ran the 1600 and 1615 updates through my scripts and ended up with 26,359 prefixes that were hijacked by ASN 23724.

Now to draw the dividing line. I added another option to my scripts to take in a list of neighbors, a list of prefixes and a baseline (file is 55 MB) whereupon processing looks through the updates and with the output (file is 33MB) being what each router’s RIB table would look like at 16:15:08 when the attack stopped (according to Routeviews), but only for the hijacked prefixes. Although geography is not quite as relevant when looking at ASNs, I was curious to know where all of these peers were. A quick search on the CIDR Report provided the name and location of most.²² The best (free) visualization source I was able to find was from CAIDA.²³ You can simply type in an ASN and it shows you all of its peers, location information, etc.

Looking at this information, it appears that several ASNs were not even aware something happened. Just to double check, I went through and grabbed all of the RIB table data and update data for every peer that said it had 0 of the hijacked prefixes from the 1600 RIB table. The neighbors highlighted in red in the chart below had no RIB table data, so their connection to the Route Views routers may have been down during this timeframe. The ones in green were active, yet still did not receive any updates regarding the hijacked networks. The important note is not all of the neighbors were affected by the hijacking.

Not all ASNs on the Internet receive the full routing table. For instance, ASN 11537, neighbor 64.57.28.241, receives ~12,600 advertisements (or at least that is how many it tells Routeviews about). ISPs do not always allow a neighbor to advertise anything it wants. This can be for a number of reasons, such as a minimal amount of security or for controlling outbound traffic for the ASN. This could also explain why some neighbors had more of the hijacked prefixes in their routing tables than others.

I want to draw attention to the fact that not all ISPs are created equal either. In fact, they are broken into tiers with the highest level being a Tier 1 ISP.²⁴ Please see the link in the end notes for more details, but Tier 1 ISPs form the backbone of the Internet and have the entire Internet routing table. Route Views peers with most Tier 1 ISPs, including ASNs 7018, 3549, 3356, 701, 2914, 3561, 1239, and 6453 (although 6453 had no information at this time). 7018 (AT&T) and 2914 (NTT) were affected by this attack, but the other Tier 1 ISPs had less than 1% of the hijacked prefixes in their routing tables. If all traffic destined to these prefixes were going to be rerouted to China, these ASNs would have to propagate the incorrect information.

So, I am confident saying the bold portion of the statement “Other servers around the world quickly adopted these paths, routing all traffic to about 15 percent of the Internet’s destinations through servers located in China” is massively overstated.¹

Now, to investigate the second portion that gave me grief. The report to Congress was very specific: “routing all traffic to about 15 percent of the Internet’s destinations”. I will approach this from a couple of different angles. If we go based just on the number of advertisements, then the attack affected less than 8.1% of the Internets destinations, which is pretty far off the claimed amount.

What if we determine the exact number of IPs affected by this hijacking? I will try to help the report’s numbers by counting overlapping IP space in the total number of hijacked IPs. This approach resulted in the total number of hijacked IP addresses being 307444736. Once again, this is a far cry from the percentage claimed in the report, as this is less than 7.16% of the IPv4 address space (2^32 addresses). Using the full IPv4 address space is a little unfair since a large chunk is not advertised, so I removed the unused and private IP address space from the equation (Multicast and RFC 1918, even expanding the RFC address space for ease of calculations) and the result is only 8.29% of the address space was hijacked.

Now, I searched for some reports to try and validate what I found. BGPMON has a great overview of what happened and their analysis of the event.²⁵ Based on their numbers, they claim only 10% of IP address space was hijacked and they found thousands of additional hijacked networks. The discrepancy between these numbers is likely due to the the location of their sensors across the Internet. The closer their sensors are to ASNs 23724 and 4134, the more information they are able gather. They also provide an opinion that this was likely a misconfiguration, not an intentional rerouting of traffic.

Conclusions

Based on what I was able to see, neither of the claims made in the Congressional Report regarding the severity of the incident are accurate. In fact, the first claim about routing all traffic to/from the hijacked destinations simply cannot be true based on the very nature of BGP and how it operates. If an ASN purposefully advertises a network in order to redirect traffic, as long as the original owner still advertises the network, only a portion of the traffic destined for the hijacked network will be rerouted.

What is more likely than a deliberate attempt to attack or sabotage certain networks using BGP as a weapon is a misconfiguration such as the accidental removal of a filter or a poorly formed filter. The Great Firewall of China is designed to block users from accessing certain sites and IP addresses. Since BGP or any routing protocol can be used to blackhole traffic (on a small scale it is very effective, but on the Internet scale it has very limited effect) it would make sense China is using routing to also restrict user traffic. By rerouting the traffic internal to their networks they can also watch who is trying to access these sites without allowing the traffic to reach the real destination. It would be critically important for these false routes not to get outside the ASN where they are being used because leaking these routes would allow outsiders to see what they are blocking and it could have a limited impact on neighbor ASN traffic which was seen with this incident.

End Notes

¹ 2010 REPORT TO CONGRESS, accessed December 2010 from United States – China Economic and Security Review Commission at http://www.uscc.gov/annual_report/2010/annual_report_full_10.pdf

² Google vs. China, accessed December 2010 from The Washington Post at http://www.washingtonpost.com/wp-dyn/content/article/2010/01/13/AR2010011302908.html

³ OSPF Design Guide, accessed December 2010 from Cisco at http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

⁴ RFC 2453: RIP Version 2, accessed December 2010 from Internet Engineering Task Force at http://tools.ietf.org/html/rfc2453#page-18

⁵ Dijkstra, E.W. A Note On Two Problems In Connexion With Graphs, accessed December 2010 from Yale at http://www.cs.yale.edu/homes/lans/readings/routing/dijkstra-routing-1959.pdf

⁶ Bellman, Richard. On A Routing Problem, accessed December 2010 from Freie Universität Berlin at http://cst.mi.fu-berlin.de/teaching/WS0607/19639-S/bellman58routing.pdf

⁷ RFC 1105: A Border Gateway Protocol (BGP), accessed December 2010 from Internet Engineering Task Force at http://tools.ietf.org/rfc/rfc1105.txt

⁸ RFC 4271: A Border Gateway Protocol 4 (BGP-4), accessed December 2010 from Internet Engineering Task Force at http://www.ietf.org/rfc/rfc4271

⁹ BGP Best Path Selection Algorithm, accessed December 2010 from Cisco at http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

¹⁰ Labovitz, Craig. Delayed Internet Routing Convergence, accessed December 2010 from Penn State at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.8308&rep=rep1&type=pdf

¹¹ McMillan, Robert. A Chinese ISP Momentarily Hijacks The Internet, accessed December 2010 from New York Times at http://www.nytimes.com/external/idg/2010/04/08/08idg-a-chinese-isp-momentarily-hijacks-the-internet-33717.html

¹² Markoff, John. Report Looks at How China Meddled With the Internet, accessed December 2010 from New York Times at http://www.nytimes.com/2010/11/18/world/asia/18intel.html?_r=1&ref=asia

¹³ Marsan, Carolyn Duffy. Six Worst Internet Routing Attacks, accessed December 2010 from Network World at http://www.networkworld.com/news/2009/011509-bgp-attacks.html

¹⁴ BGPMon, accessed December 2010 from BGPMon at http://bgpmon.org

¹⁵ Secure BPB, accessed December 2010 from BBN at http://www.ir.bbn.com/sbgp/

¹⁶ White, Russ. Securing BGP Through Secure Origin BGP, accessed December 2010 from Cisco at http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-3/securing_bgp_sobgp.html

¹⁷ Marsan, Carolyn Duffy. Fix to Chinese Internet Traffic Hijack Due in January, accessed December 2010 from Network World at http://www.networkworld.com/news/2010/120710-chinese-internet-traffic-fix.html?hpg1=bn

¹⁸ Peplnjak, Ivan. Secure BGP, accessed December 2010 from IOS Hints at http://blog.ioshints.info/2010/03/secure-bgp.html

¹⁹ University of Oregon Route Views Project, accessed December 2010 from University of Oregon at http://www.routeviews.org/

²⁰ MRT Routing Information Export Format, accessed December 2010 from Internet Engineering Task Force at http://tools.ietf.org/id/draft-ietf-grow-mrt-04.txt

²¹ Zebra Dump Parser, accessed December 2010 from Clarkson at http://web2.clarkson.edu/projects/itl/HOWTOS/bgpAnalysis/tools/downloads/zebra-dump-parser/

²² CIDR Report, accessed December 2010 from CIDR-Report at http://www.cidr-report.org/as2.0/

²³ AS Rank:Information for a single AS, accessed December 2010 from The Cooperative Association for Internet Data Analysis at http://as-rank.caida.org/?mode1=as-valid-links&mode0=as-info&as=4134&Find+this+AS=Find+this+AS

²⁴ Winther, Mark. Tier 1 ISPs: What They Are and Why They Are Important, accessed December 2010 from IDC at http://www.ntteuropeonline.com/fileadmin/media/PDF/IDCTier1-Whitepaper.pdf

²⁵ Chinese ISP Hijacks the Internet, accessed December 2010 from BGPMon at http://bgpmon.net/blog/?p=282