Final BGP Project_v1.1

BGP Hijacking Experiment

SAN JOSE STATE UNIVERSITYBGP Hijacking ExperimentSpring EE209, Professor Tarng

5/6/2014

Table of ContentsTable of Contents1Table of Figures2Overview3Software Tools3Experiments4Event Timeline4BGP Prefix Hijack Attacks5(DETERLAB LAB EXPERIMENT)5Attack Defenses and Analysis14Conclusion21

Table of FiguresFigure 1: Network Topology5Figure 2: Traceroute performed on Client machine to FTP server6Figure 3: Client Routing table7Figure 4: Client BGP routing table7Figure 5: ASN3 BGP routing table8Figure 6: ASN2 BGP routing table8Figure 7: README file for prefix hijacking10Figure 8: ASN3 BGP table after prefix hijacking10Figure 9: ASN2 BGP table after prefix hijacking11Figure 10: Traceroute for sub prefix hijack11Figure 11: FTP file from server11Figure 12: README file using sub prefix hijacking12Figure 13: ASN3 BGP routing table after sub prefix hijack12Figure 14: ASN2 BGP routing table after sub prefix hijack13Figure 15: Detection Algorithm [13]17Figure 16: Reactive Detection System [1]19Figure 17: Reactive Defense Analysis [1]20Figure 18: Proactive and Reactive Defense Comparisons [1]21

OverviewThe Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. The reachability information in BGP provides data of the list of the Autonomous Systems the packet traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which the routing loops may be pruned and some policy decisions may be enforced at the AS level.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). BGP-4 also introduces the mechanisms that allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination based forwarding paradigm. Router forwards the packet based solely on the destination address carried in the IP header of the packet.IP Hijacking also called BGP Prefix Hijacking is the illegitimate takeover of groups of IP addresses by corrupt Internet routing tables. At the global level, individual IP addresses are grouped together into prefixes. These prefixes will be originated or owned by the autonomous system (ASes) and the routing tables between them are maintained using the Border Gateway Protocol (BGP). Hackers can use IP hijacking for various types of malicious attacks such as spamming and DoS attacks targeting specific entities. Attackers may also use hijacked IP addresses to reroute bank transactions and emails. In order to defend against these hackers, system administrators must detect and be aware of any unauthorized announcement of address prefixes. Prefixes that have been hijack will belong to two different ASes and will lead to a Multiple Origin AS (MOAS) which will conflict in routing tables .BGP Hijacking can occur deliberately or by accident in one of the several ways: An AS announces that it originates a prefix that it does not actually originate. An AS announces a more specific prefix than announced by the true originating AS. An AS announces that it can route the traffic to the hijacked AS through a shorter route than is already available, regardless of whether or not the route actually exists.

Software Tools Quagga Routing Suite: Quagga is cross platform routing software package which can be installed on a general purpose machine and turn it into software based router. Traceroute: The traceroute prints the route packets take to destination host and responds with a * error in case some intermediate nodes are unreachable. Netstat: Prints the IP forwarding table of a host, active connections of each protocol, packet statistics

ExperimentsPart 1: Observe the characteristics of the network when there is no hijacking attack and retrieve a file from an ftp server.Part 2: Assume the role of an attacker and perform prefix hijacking attack. Goal is to take over the address of the ftp server and serve a forged document.Part 3: Perform sub prefix hijacking attacks and observe the difference between prefix hijacking and sub-prefix hijacking Event TimelineTasksDateTasks Completed By

BGP hijacking ProposalMarch 18th, 2014Ashish (Writer), Gaurav (Proof read), Vincent (Proof read)

Perform BGP hijackingMarch 27th, 2014Ashish (part 1), Gaurav (part 2), Vincent (part 3)

Write DETER reportMarch 27th, 2014Ashish (part 2), Gaurav (part 2), Vincent (part 3)

Compile DETER reportMarch 29th, 2014Ashish (Proof read), Gaurav (Compile report), Vincent (Proof read)

BGP Defenses ReportApril 13th, 2014Ashish (Writer), Gaurav (Proof read), Vincent (Proof read)

BGP Defense Analysis ComparisonApril 25th, 2014Ashish (Proof read), Gaurav (Proof read), Vincent (Writer)

Team Meeting May 2nd, 2014Attendees: Ashish, Gaurav, Vince. Discussion about presentation specifics and detailed review of experiment.

Presentation SlidesMay 4th, 2014Ashish (Proof read), Gaurav (Writer), Vincent (Proof read)

Compile Final ReportMay 4th, 2014Ashish (Proof read), Gaurav (Proof read), Vincent (Compile report)

Record ExperimentMay 4th, 2014Ashish (Recorder), Gaurav (Proof read), Vincent (Proof read)

Team MeetingMay 4th, 2014Presentation Rehearsal by all members

Final PresentationMay 6th, 2014Final presentation and submission of project documents.

BGP Prefix Hijack Attacks(DETERLAB LAB EXPERIMENT)A. Network Topology:

Figure 1: Network TopologyThe network in this exercise is designed to simulate a small scale Internet with several Autonomous Systems and a simple client-server scenario. Figure 1 shows the network, where each AS has a single router. The client, server, and attacker hosts all directly attach to their adjacent routers inside the respective ASes. The ftp server attaches to router asn1 (which belongs to AS 65001) and has the IP address 10.1.1.2, while the client attaches to router asn3 (AS 65003) and has the IP address 10.5.0.2. The attacker ftp server attaches to router asn4 (AS 65004) and also has the IP address 10.1.1.2. Initially, the attacker ftp server is not accessible from the anywhere in the network except router asn2 i.e., only router asn4 knows about the attacker. The router asn1 announces a route for 10.1/16 network, which covers the real ftp server 10.1.1.2, therefore any packets sent to this address will reach the ftp server (until the prefix is hijacked).

B. Part 1: Understanding the Topology

1. Login to theclientmachine and perform the following tasks:On the command prompt run:traceroute -n 10.1.1.2and record the output of the command (if you see * *s in the output, run the command again). Explain the path from client host 10.5.0.2 to the ftp server host 10.1.1.2. Specifically, note down the intermediate hops and their IP addresses. How many hops away is the ftp server from the client? Recorded output after executing traceroute -n 10.1.1.2 commandsjs209ak@client:~$ date;traceroute -n 10.1.1.2;dateThu Mar 27 12:55:29 PDT 2014traceroute to 10.1.1.2 (10.1.1.2), 30 hops max, 60 byte packets 1 10.5.0.1 0.216 ms 0.215 ms 0.208 ms 2 10.3.0.2 0.666 ms 0.670 ms 0.665 ms 3 10.2.0.1 1.136 ms 1.132 ms 1.126 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * *10 * * *11 * * *12 * * *13 * * *14 * * *15 * * *16 * * *17 * * *18 * * *19 * * *20 * * *21 * * *22 * * *23 * * *24 * * *25 * * *26 * * *27 * * *28 * * *29 * * *30 * * *Thu Mar 27 12:55:59 PDT 2014Figure 2: Traceroute performed on Client machine to FTP server The client host (10.5.0.2) is connected to the FTP server (10.1.1.2) via asn3 (10.5.0.1)-asn2 (10.3.0.2)-asn1 (10.2.0.1). The above traceroute output provides us the detailed path packet takes in order to reach the FTP server. From the above configuration and network topology we see that the client is 3 hops away from the ftp server.

2. Runnetstat -rnand record the output. Explain how the client is able to send packets to 10.1.1.2, i.e., what route is the client using to reach the server 10.1.1.2 (don't forget to list the gateway address and mask value).

Executing Given Commands:

sjs209ak@client:~$ date;netstat -rn;dateThu Mar 27 12:58:16 PDT 2014Kernel IP routing tableDestinationGatewayGenmaskFlagsMSSWindowirttIface

10.5.0.00.0.0.0255.255.255.0U000eth0

192.168.0.00.0.0.0255.255.252.0U000eth1

10.0.0.010.5.0.1255.0.0.0UG000eth0

0.0.0.0192.168.1.2540.0.0.0UG000eth1

Thu Mar 27 12:58:16 PDT 2014Figure 3: Client Routing table The netstat output provides the usable route which is used by the host client. The host client (10.5.0.2) sends packet to its immediate connected node asn3 (10.5.0.1 255.0.0.0) out from eth0. The client is using gateway IP 10.5.0.1 255.0.0.0 to reach the FTP server 10.1.1.2. The flag for netstat output is described below:GRTF_GATEWAYDestination requires forwarding by intermediary

URTF_UPRoute usable

3. Runsudo vtysh -c "show ip route"and record the output. Does the "information" (not the raw output) differ from the above output? If so, what additional information can you learn from this output?sjs209ak@client:~$ date;sudo vtysh -c "show ip route";dateThu Mar 27 12:59:50 PDT 2014Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB routeK>* 0.0.0.0/0 via 192.168.1.254, eth1S>* 10.0.0.0/8 [1/0] via 10.5.0.1, eth0C>* 10.5.0.0/24 is directly connected, eth0C>* 127.0.0.0/8 is directly connected, loC>* 192.168.0.0/22 is directly connected, eth1Thu Mar 27 12:59:50 PDT 2014Figure 4: Client BGP routing table We see there are no major differences in both this and the above netstat output. The only difference is that, this output says that the host takes 10.5.0.0/24 to reach its immediate node 10.5.0.1, whereas the netstat provides clearer IP information of this node. Both provide information on the usable routes/connected routes to the host client (10.5.0.2).The additional information we get is: Static/Connected routes are properly described Loopback address is provided in this output

4. Runftp 10.1.1.2and at the prompt for username typeanonymous, type some random text for password. Once you are connected to the ftp server, typeget READMEat the ftp prompt. After the README file finishes downloading, logout (typeexit) and read and contents of the README file. What does it say?

README file contents: AS1 owns the prefix for 10.1/16

5. Now login toasn3machine and perform the following tasks (it helps to keep a separate terminal for each host you need to login):Runsudo vtysh -c "show ip bgp"and record the output. What is the AS path to reach 10.1/16?

sjs209ak@asn3:~$ sudo vtysh -c "show ip bgp"BGP table version is 0, local router ID is 10.3.0.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R RemovedOrigin codes: i - IGP, e - EGP, ? - incomplete

NetworkNext HopMetricLocPrfWeightPath

*> 10.1.0.0/1610.3.0.2065002 65001 i

*> 10.5.0.0/160.0.0.0032768i

*> 10.6.0.0/2410.4.0.20065004 i

Figure 5: ASN3 BGP routing table The AS path to reach the 10.1/16 network is 65002 65001 i

6. Login toasn2machine and perform the following tasks:Runsudo vtysh -c "show ip bgp" (no need to record output). What AS path will be used to reach an IP address 10.1.1.2? What AS path will be used to reach an IP address 10.1.2.2?

sjs209ak@asn2:~$ vtysh -c "show ip bgp"Exiting: failed to connect to any daemons.sjs209ak@asn2:~$ date;sudo vtysh -c "show ip bgp";dateThu Mar 27 15:16:03 PDT 2014BGP table version is 0, local router ID is 10.2.0.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R RemovedOrigin codes: i - IGP, e - EGP, ? - incomplete

NetworkNext HopMetricLocPrfWeightPath

*> 10.1.0.0/1610.2.0.10065001 i

*> 10.5.0.0/1610.3.0.10065003 i

*> 10.6.0.0/2410.3.0.1065003 65004 i

Figure 6: ASN2 BGP routing table To reach both the IP address the packets will take the same AS path 65001 i.C. Part 2: Prefix Hijacking1. Runtraceroute -n 10.1.1.2and record the output of the command (if you see * *s in the output, run the command again). Explain the path from client host 10.5.0.2 to the ftp server 10.1.1.2. How many hops away is the ftp server from the client this time? Is there a difference in output from the same command in Part-1?

Recorded output after executing traceroute -n 10.1.1.2 command

FTP server is still 3 hops away from the client but the path has changed. It takes path from 10.5.0.1 to 10.4.0.2 to 10.1.1.2 (Total: 3 hops) There is a difference in output from the same command in part1. In Part 1 the hops are 10.5.0.1 10.3.0.2 10.2.0.1 in this part traceroute shows hops 10.5.0.1 10.4.0.2 10.1.1.2

2. Runftp 10.1.1.2and at the prompt for username typeanonymous, type some random text for password. Once you are connected to the ftp server, typeget READMEat the ftp prompt. After the README file finishes downloading, logout (typeexit) and read and contents of the README file. What does it say? Did the contents of README file differ from the output in Part-1?

Executing given commands:

Reading contents of the README:

README file contents: I just hijacked your BGP Prefix! which is different as compare to Part 1 which was AS1 owns the prefix for 10.1/16 Following window shows the contents of README file:

Figure 7: README file for prefix hijacking

3. Login toasn3machine and perform the following tasks:Runsudo vtysh -c "show ip bgp"and record the output. What is the AS path to reach 10.1/16? Did the AS path differ from the last time (i.e., part-1)? Recorded output after executing sudo vtysh -c "show ip bgp command

Figure 8: ASN3 BGP table after prefix hijacking AS path to reach 10.1/16 is 65004i The AS path differs from the part-1 AS path, which was 65002 & 65001 i

4. Login toasn2machine and perform the following tasks:

Runsudo vtysh -c "show ip bgp"(no need to record output). What AS path will be used to reach an IP address 10.1.1.2? What AS path will be used to reach an IP address 10.1.2.2? Recorded output after executing sudo vtysh -c "show ip bgp command

Figure 9: ASN2 BGP table after prefix hijacking AS path to reach an IP address 10.1.1.2 is 65001i AS path to reach an IP address 10.1.2.2 will be 65001i

D. Part 3: Subprefix Hijacking1. Runtraceroute -n 10.1.1.2(no need to record output). How many hops away is the ftp server 10.1.1.2 from the client this time? Is there a difference in output from the same command in Part-2? Recorded output after executing traceroute -n 10.1.1.2 command

Figure 10: Traceroute for sub prefix hijack FTP server is still 3 hops away from the client but the path has changed. It takes path from 10.5.0.1 to 10.4.0.2 to 10.1.1.2 (Total: 3 hops) There is no difference in output from the same command in part-22. Runftp 10.1.1.2and at the prompt for username typeanonymous, type some random text for password. Once you are connected to the ftp server, typeget READMEat the ftp prompt. After the README file finishes downloading, logout (typeexit) and read and contents of the README file. Did the contents of README file differ from the output in Part-2? Executing given commands:

Figure 11: FTP file from server

Reading contents of the README:

README file contents: I just hijacked your BGP Prefix! which is same as part-2

Figure 12: README file using sub prefix hijacking3. Login toasn3machine and perform the following tasks:Runsudo vtysh -c "show ip bgp"and record the output. What is the AS path to reach 10.1/16? Did the AS path differ from Part-2? What is the AS path to reach 10.1.1.0/24? Recorded output after executing sudo vtysh -c "show ip bgp command

Figure 13: ASN3 BGP routing table after sub prefix hijack The AS path to reach 10.1/16 would be 65004 or no preferred path 65002->65001 The AS path to reach 10.1.1.0/24 is 65004

4. Login toasn2machine and perform the following tasks:Runsudo vtysh -c "show ip bgp"(no need to record output). What AS path will be used to reach an IP address 10.1.1.2? What AS path will be used to reach an IP address 10.1.2.2? Recorded output after executing sudo vtysh -c "show ip bgp command

Figure 14: ASN2 BGP routing table after sub prefix hijack The ASPATH used to reach 10.1.1.2 is 65001 through next hop 10.2.0.1 because it is the preferred path signified by the *> The ASPATH used to reach IP address 10.1.2.2 is 65001 through next hop 10.2.0.1 because it is the preferred path signified by the *>

Attack Defenses and Analysis1. IntroductionA variety of services like the Voice over IP, video and audio buffering and downloading, bank transactions, etc are carried over communication networks like the Internet. These are vulnerable services and are under constant security threats. These security threats have a large impact on both the service providers and customers. Major ISPs use BGP to propagate information about Internet destinations and how to reach those [2]. In prefix hijacking, a malicious Border Gateway Protocol (BGP) router originates an IP prefix that the router does not own [1]. Traffic is thus diverted away from the destination to the malicious BGP router.Todays Internet routing system is still largely unprotected. IP Prefix Hijacking attack threatens the Internets routing infrastructure. Fundamentally, the inherent assumption of self-policing and trust among participants of BGP [3, 4], the inter-domain routing protocol responsible for exchanging routing information among thousands of Autonomous Systems (ASes) in order to route the traffic globally, opens up the possibility of false route announcements to infiltrate the routing infrastructure. The hijacker or the attacker either originates an AS path announcement for an IP prefix not owned by the routers AS or announces for target prefix an AS path consisting of non-existent links. Such false announcements causes the attacker routers AS to be very attractive for forwarding traffic towards the target IP prefix [2]. In essence, the trust model is based on endpoints. After a pair of ISPs agrees to use BGP to exchange routing information, each ISP specifies the address of a router that the ISP will use. Each side configures its BGP to speak BGP with the other ISPs router [2]. Because of the endpoints explicit configuration, a trust level is created which prevents the ISP from accepting BGP advertisements from a random site. Once BGP endpoints are configured, the protocol blindly trusts all advertisements sent by the other side without checking the validity of the data it receives. There are no mechanisms to validate data in BGP protocol. Consequently, if an erroneous route is accidentally created at one endpoint, BGP will advertise the routes to its peers and the peer will accept the route, thereby polluting the forwarding table. The peer will then advertise to its peers and the error can propagate across the entire Internet. Thus, a small error at one endpoint has the potential to be catastrophic.Despite many proposals such as So-BGP [5], SBGP [6], and SPV [7], there are still no widely deployed effective prevention and mitigation solutions against routing attacks such as IP prefix hijacking. There exists two main problems viz., changes in the BGP routing protocol and a significant increase in the complexity and computational overhead. Practices like route filtering, is used to handle many of the common problems. That is, when configuring BGP, an ISP specifies a set of prefixes that should be filtered in incoming advertisements [2]. IP prefix hijacking can be performed in several ways. Regular prefix hijack occurs when a route to an existing IP prefix of the victim network is originated by the attacker router. As a result, the Internet is partially polluted, depending on how preferable the bogus route is compared to the valid route from the perspective of various networks. Sub prefix hijack results from stealing a subnet of an existing prefix in the routing table by announcing a route for the subnet originating from the attacker network. Due to longest prefix match based forwarding, most networks are polluted. Detection can be made difficult by disguising both attack types with manipulated AS paths without modifying the origin AS, while making the traffic traverse through the attacker network [1].

2. DefensesTwo main approaches to defend the network against various security attacks are discussed, viz. proactive prevention and reactive mitigation. Ideally, it is better to employ prevention, as it aims to eliminate attacks. However, due to Internet comprising of heterogeneous networks, there is a lack of global adoption of necessary changes required for prevention. Furthermore, there is always the possibility of network misconfiguration. Thus, proactive prevention alone is never sufficient. Reactive mitigation, on the other hand, depends on the accurate and timely detection of systems to be effective [1]. A reactive mechanism monitors routes, looks for indications that a problem has occurred, and then creates a response accordingly. A proactive mechanism monitors incoming BGP advertisements, looks for indications that a given advertisement will cause problems and tries to prevent the problem from occurring [2]. We must therefore combine techniques of both proactive prevention and reactive mitigation.A study conducted by Tongqing Qiu, Lusheng Ji, Dan Pei, Jia Wang and Jun (Jim) Xu, "TowerDefense: Deployment Strategies for Battling against IP Prefix Hijacking", Georgia Institute of Technology, AT&T Labs-Research, discusses the detection of prefix hijacking attack by deploying agents in the region within which the routers are polluted with false routes entries injected by the attack. The routing information that these agents gather, from either the control or data plane or both, may contain attacker altered routes, which is critical information on which any detection mechanism depends on.A hijack prevention system must have the following salient features [2]: Proactive Behaviour: Since, most hijacks last for only a few hours, a defense system needs to act quickly to prevent the acceptance and propagation of incorrect routes. Reactive schemes do not provide sufficient protection and suffer from long delays before detection completes. Broad Hijack Coverage: The defense mechanism should handle both prefix hijacks and subnet prefix hijacks. It should also flag bulk prefix announcements. Validation of subnet prefixes presents a challenge. Since the longest-match rule gives subnet prefixes the potential to cause severe problems, BGP must be cautious before accepting a subnet prefix. However, BGP must accept the authoritative subnet prefixes because rapid recovery relies on subnet prefix announcements. Prefix Ownership Validation: Validation of an origin is not straightforward. Registry databases are inconsistent as a substantial fraction of IP prefixes are unregistered. Further-more, the registries do not exchange information. Various regional registries are considered to be inconsistent and unstable [8]. Thus, unregistered prefixes can be handled by a history-based approach. Support for Recovery: One of the biggest challenges of history-based systems such as PHAS [9] or PGBGP [10] arises once a victim announces a subnet prefix to reverse the effect of a hijack. History-based techniques flag the announcement and either ignore it or propagate it with a lower preference than the full prefix. Thus, a false positive occurs, disabling any recovery attempt. Practical: To be practical, a defense system can-not require changes in the underlying transport protocols (i.e., cannot change IP or TCP). Furthermore, a hijack mechanism cannot require manual updates or extensive configuration.

An attacker can evade detection if any of the following is true for all the monitoring nodes in a proactive defense scheme [1]: The victim route is a customer or peer route, and the attacker route is a provider route. The victim route is a customer route, the attacker route is a provider or peering route. Both the victim and the attacker routes have the same profit-driven preference but the victim route is shorter.The ways to detect BGP hijacking are best done through a collaborate effort between ASes. To detect spoofed routes it is important to know the assigned and allocated prefixes in the Internet and their authentic source ASes. There are also databases such as ARIN and other large ISPs that maintain routing information. This method to detect BGP hijacking is extremely difficult because the databases need to be kept 100% accurate, real time, and up to date. This leads to development of real time detection of false routes. A detection system must contain dynamic information based on two types of routing information, namely the associations between prefixes and origin ASes, and peering status between ASes. The intuition behind the two routing information is because these values are relatively stable over time and can be learned. When the detection scheme senses that there are objects that look unfamiliar then the route may be a bogus route. The detection scheme is also bolstered by the historical database information that it can look up to make bogus routes easier to detect. The efficacy of this system yields a 0.2% false positive rate and a 0% false negative rate.The architecture of the real time BGP detection system consists of a database that can peer with BGP routers and passively receive routing data. The database stores routing information and inspects the legitimacy of the route. Detection systems are best deployed by a Tier 1 service provider to protect its routing system [13]. Neighbouring ASes also allow the detection system to receive routing information. The routing data used by the database includes the prefix designated by p and AS path designated by (ak.a0). The extracted prefixs AS destination is denoted by a0 and is considered downstream from all other ASes. The downstream and upstream direction of the path is key to encoding import and export route policies of the ASes. Downstream ASes allows exporting of routes to the upstream AS while upstream ASes allow for imports of routes to the downstream ASes.In the algorithm presented below we find that the route is indicated by (p, {ak,.,a0}) and the ISBOGUSROUTE function is used to verify the legitimacy of the route [13]. The legitimacy of the link is first verified link by link as the variable k is decremented to 1. If the condition fails then the function will return a False indicating the route is bogus. The second check within the ISBOGUSROUTE function is the ISLEGITIMATEASSOCIATION which will take the prefix and destination AS and check if the information is legitimate. The ASes can aggregate or de-aggregate prefixes which can both be considered legitimate. If the prefix P and subnet p are assigned to two different ASes then we need to consider the possibility that an AS A can have a prefix that is assigned to a subnet from AS B. As a result if the path is not an immediate subnet of a prefix P and not a part of the destination prefix then there is a returned False route.The route is classified as path spoofing if the ISBOGUSROUTE function returns a false under the conditions of an AS-link. If the link is not legitimate in one direction, but the other direction is legitimate then the import/export policy is violated for the AS. Since the path is legitimate in one direction, then we must also check all other attached links since the other AS links would be invisible under normal or reverse operating conditions. If one link is reversed then the route is classified as redistribution path spoofing; otherwise it would be considered a fake-link path spoofing [13].The route is classified as a prefix hijacking route if the AS path is valid, but the prefix does not match with the destination AS. Additionally, if the association between prefix is legitimate, but the algorithm detects that the origin AS is different, this is classified as duplicate prefix hijacking. Sub-prefix hijacking occurs if p is the immediate subnet of prefix P. Super prefix hijacking occurs if the prefix q is the immediate subnet of p [13]. The algorithm discussed and details of the different classes of hijacking will aid in the understanding of reactive defenses.

Figure 15: Detection Algorithm [13]2.1 Reactive Defense:Detection based response in reactive defense mechanism relies on human intervention. We require a reactive, detection-assisted mitigation scheme that automatically responds to detected prefix hijacks and hence mitigates the adverse impact of the attacks in a timely fashion. Reactive mitigation can be classified into network-based and end-host based schemes [1]. Network based detection and response requires cooperation from network elements inside the core of the Internet and may suffer from increased route convergence delays. In contrast, an end-host based approach can be more readily deployed by end-users at the edge of the network. However, it has more limited scope of effectiveness as it usually relies on application layer techniques such as overlay routing to bypass polluted networks.Ideally, all ASes in the Internet participate and helps in the complete removal of the bogus routes. However, it is difficult to deploy it globally [1]. Typically, the role of protecting the routes is taken up by the large ISP ASes (sometimes referred as lifesavers), through which many network paths are traversed. These lifesavers can easily deploy security features for detecting the bogus routes. The mitigation actions executed by these lifesavers remain effective until the original bogus route is withdrawn, at which point the lifesavers are directed by the mitigation systems to revert to the previous state before the attack.The mitigation system, upon detecting a prefix hijack attack, is notified by the detection system with three pieces of information viz., the attacker AS, the victim AS and the victim prefix. Such information allows any AS to differentiate bogus routes which end with the attacker AS and valid routes which end with the victim AS. The mitigation system then contacts the lifesavers and instructs it to perform the following: Bogus Route Purging: The AS of the lifesavers, deletes the bogus routes from its routing table. Due to the large size of the AS, the bogus route propagation is throttled. Bogus route purging blocks the bogus routes by deleting it. This is possible with even just a few well-connected ASes taking this action. Valid route promotion: A subset of the lifesavers is chosen by the mitigation system to further perform route promotion for the valid route to the victim AS. Each selected promoter AS modifies the valid route by moving all ASes in the path onto a separate set and operations like route aggregation [11][12] is carried out to effectively shorten the AS path to the prefix. By exploiting this set, route promotion makes valid routes more attractive in the BGP best route selection process, since the AS path length is effectively shortened. To maximise the promotion effect the promoter AS announces to all its neighbours the shortened promotion route, as if the victim prefix is the promoters own prefix. The side effect of this promotion is that some AS that were not polluted may select valid routes that are longer, that is, these ASes experience prolonged paths.Since route purging is performed on all the large ASes of the ISP while route promotion is performed on one or a few ASes, the effectiveness of the mitigation scheme is determined by both the strategy of selecting the larger ASes in the Internet when deploying the mitigation system and the strategy of selecting the promoter AS among these ASes when a prefix hijack is detected.The selection of lifesavers affects the effectiveness of bogus route purging [1]. The selection is challenging because they are selected prior to attacks whose location is not known yet. Intuitively, choosing the lifesaver amongst the most well-connected ASes would best throttle the propagation of bogus routes and hence maximize the benefit. Lifesaver selection happens during deployment and is therefore based on static AS topological properties.The selection of the promoter directly affects the effectiveness of valid route promotion [1]. In this, the promoter effectively takes over the victim prefix from the victim AS and announces the prefix as the promoters own. This behavior is similar to the case where the promoters own prefix is hijacked by the attacker. So the benefit of valid route promotion is closely related to the promoters resilience against the attacker, that is, how well the promoter can protect its own prefix against the hijack. Therefore choosing the most resilient AS against the attacker maximizes the effectiveness of valid route promotion. The most resilient ASes are the ones with large number of providers. Furthermore, because the selection of lifesavers dictates where the promoter comes from, resilience is also considered in the lifesaver selection strategy. Promoter selection happens after the attack detection and hence uses information on the victim and the attacker.Route purging is beneficial in providing some protection against prefix hijack. This is because of the route diversity at these lifesavers. The well-connected lifesaver has many neighbors that provide many routes to a destination prefix [1]. It is unlikely that all the neighbors are polluted, and hence the lifesaver is highly likely to find a valid route. Route purging along with promotion achieves higher benefit than bogus routing route purging alone as in BGP decision process, path length is not the only deciding factor. Local preference dictated by AS relationship overrides path length. When an attack is detected shown in figure 15, the detection algorithm previously discussed notifies the mitigation system about the attack with three pieces of information. The information included is the attacker AS, victim AS, and victim prefix. Given this information the lifesaver AS is able to purge the bogus route and promote the valid route. In figure 16 the lifesaver AS deletes the bogus route and stops bogus route propagation, therefore purges the bogus route from its table. Figure 16 shows that after purging the route the lifesaver AS must promote a valid route to assist in the recovery of nearby polluted neighbors. The lifesaver AS will modify the valid route by moving ASes in AS_PATH into an AS_SET [1]. As a result, the AS_SET shortens the AS path to a prefix by announcing a shortened promotion route as if the victims prefix is the lifesavers prefix. The promoted path will look much more attractive because BGP protocol specifies that AS_SET contributes only one to the path length no matter the amount of ASes present in the AS_SET. In a realistic scheme, the lifesaver AS will have many neighbors to provide diverse routes to a destination prefix and therefore is less likely for all neighbors to be polluted. Less pollution will maximize the chances of the lifesaver AS to find a valid route and purge bogus routes.A negative effect of route promotion is potentially suboptimal route selection [1]. The route promoter can oversell its route, that is, when the actual length of the promotion route is longer than the length calculated in the BGP decision process. The path inflation is defined as the relative AS path length increase experienced by each AS after the promotion compared to the original AS path length.

Figure 16: Reactive Detection System [1]

2.2 Comparing Reactive Defenses:Reactive detection have a few schemes that vary according to the level of security and detail that ISPs want to obtain. Success of each strategy is highly dependent on the number of attackers that are present and the number of lifesaver ASes. The first strategy is a purge only strategy, and the experimental effectiveness when cooperating with 24 ASes ranges from 18%-38% pollution of ASes. The second strategy is to include promotion of valid routes. The chances of polluted ASes are much lower in this scheme because border gateway routers will announce much shorter paths when the path is moved from AS_PATH into an AS_SET. With this scheme we can mitigate about 8% chances of AS pollution for a range of about 10%-30%. The third strategy is an all promotion, which means that both purging and promotion strategies are used to fend off against pollution. With this defensive strategy, pollution is highly reduced and gives about a 1%-10% chance of AS pollution. Observe that in figure 17, that the less lifesaver routers present, the more similar the purging, single-promotion, and all-promotion schemes resemble each other. Under these results we can safely assume for a reactive strategy to work well there must be sufficient involvement from many lifesaver ASes.

Figure 17: Reactive Defense Analysis [1]

2.3 Proactive defenses:Early detection is important. A mechanism that spends many minutes to detect a hijack may miss a significant percentage of the hijack. A proactive mechanism offers rapid detection and prevention can minimise disruption, however, all solutions pose a tradeoffs. A proactive solution can err by being too conservative [2]. For example, in the extreme case, the proactive filter will block all advertisements until each route has been verified manually, defeating the ability of Internet routing to accommodate failures quickly and automatically. Even if a proactive mechanism only introduces a moderate delay, it may not accept legitimate route changes quickly, meaning that old routes will persist longer after a network or router failure.Customer route filtering primarily acts as a first defense to filter out some of the BGP hijacking attacks. ISPs will typically provide customer route filtering to prevent customers from injecting bogus routes [1]. The ISP maintains a route registry with its direct customers and each customer registers its prefix with the ISP AS. This registry can be propagated down to the edge consumers. Route filtering is performed at each BGP session between the ISP AS and the direct customers. The direct customers will announce any route and the ISP AS will block routes with any unregistered prefixes. While route filtering is potentially effective, ISPs performing route filtering rely on the up-to-date route registries. Practically, route registries can be maintained separately or shared. Although a local registry is relatively easier to maintain than a global registry, it still requires coordinated efforts to synchronise the registries owned by different providers. Reassignment or new assignment of a prefix requires updates to the multiple registries of all the providers of the prefix owner that are higher up in the AS hierarchy [1].

2.4 Comparing Proactive and Reactive Defenses:Proactive and reactive defense both offer very capable defenses when the number of participating ASes are high in quantity. In a simulated prefix hijacking experiment we can isolate the two defensive cases. First, we have a proactive scheme in figure 18 denoted with the triangular line graph. When forty ASes participate the chances of polluted ASes are about 25%. In comparison, the reactive scheme using 40 participating ASes shows a 8% chance of pollution. The amount of reduced amount is three fold and signifies that a purge and promotion strategy is much more effective. Purge and promotion is a much more effective defensive strategy because the AS that implements route purging will not import bogus routes. Meanwhile, Customer Route Filtering is still capable of importing bogus routes because an AS does not perform filtering on links to its peers or providers. There are also certain cases in which filtering is completely ineffective due to a defense-incapable link between the attacker and victim [1].

Figure 18: Proactive and Reactive Defense Comparisons [1]

ConclusionHijacking attacks pose a significant threat to the Internet and can have devastating consequences on Internet services [14]. However, effective defenses against these attacks have not yet deployed in the Internet. BGP is a routing protocol used to exchange routing information between different networks. BGP, along with other infrastructure protocols was designed with little consideration for protection of information it carries [15]. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge or replay data any of which has the potential to disrupt the overall network routing behavior. As a TCP/IP protocol, BGP is subject to all the TCP/IP attacks like IP spoofing, session stealing, etc. Any outsider can inject believable BGP messages into the communication between BGP peers and thereby inject bogus routing information or break the peer-peer connection. Any break-in the peer-peer communication has a ripple effect on routing that can be widespread.BGP is an integral part of the internet and Internet Service Providers rely on it for efficient packet delivery. Although BGP is a very powerful protocol, it is also a vulnerable protocol that could greatly damage companies if used incorrectly. As network engineers we learned to be able to recognize such BGP misconfiguration or attackers. In this project we learned how to form our own attacks and find defenses to protect inter-domain routing. It is very important to find trust between neighboring autonomous systems and have BGP properly configured to prevent corruption of BGP routing tables. DETERLAB has been a great tool to help us understand the value of network security

References:

[1] Zheng Zhang, Ying Zhang,Y.Charlie Hu and Z. Morley Mao, Purdue University and University of Michigan, "Practical Defenses Against BGP Prefix Hijacking"[2] Douglas Comer, Parmjeet Singh and Subramanian Vasudevan, "Towards A Practical and Effective BGP defense System", International conference on Intelligent Computational Systems (ICICS'2012) Jan. 7-8, 2012 Dubai[3] Tongqing Qiu, Lusheng Ji, Dan Pei, Jia Wang and Jun (Jim) Xu, "TowerDefense:Deployment Strategies for Battling against IP Prefix Hijacking", Georgia Institute ofTechnology, AT&T Labs-Research,[4] Y. Rekhter, T. Li, and S. Hares, Border Gateway Protocol 4, Internet Engineering Task Force, RFC 4271, Jan. 2006.[5] J. Ng. Extensions to BGP to Support Secure Origin BGP (soBGP), Oct. 2002. Internet Draft draft-ng-sobgp-bgp-extensions-00.[6] S. Kent, C. Lynn, and K. Seo. Secure Border Gateway Protocol (Secure-BGP). IEEE Journal on Selected Areas in Communications (JSAC), 18(4):582{592, Apr. 2000.[7] Y.-C. Hu, A. Perrig, and M. Sirbu. SPV: A Secure Path Vector Scheme for Securing BGP. In Proc. ACM SIGCOMM, 2004.[8] K. Sriram, O. Borchert, O. Kim, P. Gleichmann, and D. Montgomery, A Comparative Analysis of BGP Anomaly Detection and Robustness Algorithms, Proc. of the 2009 Cyber security Applications & Technology Conference for Homeland Security, 2009, pp 25-38.[9] M. Lad, D. Massey, D. Pei, Y. Wu, B. Zhang, and L. Zhang, PHAS: A Prefix Hijack Alert Sys-tem, 2006.[10] J. Karlin, S. Forrest, and J. Rexford, Pretty Good BGP: Improving BGP by Cautiously Adopting Routes, Proc. of the 2006 IEEE International Conference on Network Protocols, 2006, pp 290-299.[11] A Border Gateway Protocol 4 (BGP-4), Jan. 2006. RFC 4271.[12] BGP-4 Implementation Report, Jan. 2006. RFC 4276.[13] Jian Qiu, Lixin Gao, Supranamaya Ranjan, Antonio Nucci, Department of ECEm Univ, of Massachusetts, Detecting Bogus BGP Route Information: Going Beyond Prefix Hijacking[14] Philip Smith, BGP for Internet Service Providers, NANOG 25, Toronto, Canada[15] S. Murphy, BGP Security Vulnerabilities Analysis, Network Working Group, Sparta Inc., January 20061