SAN JOSE STATE UNIVERSITY

BGP Hijacking
Experiment
Spring EE209, Professor Tarng

Table of Contents
Table of Contents........................................................................................................................ 1
Table of Figures.......................................................................................................................... 2
Overview.................................................................................................................................... 3
Software Tools............................................................................................................................ 3
Experiments............................................................................................................................... 4
Event Timeline............................................................................................................................ 4
BGP Prefix Hijack Attacks........................................................................................................... 5
(DETERLAB LAB EXPERIMENT).................................................................................................... 5
Attack Defenses and Analysis.................................................................................................. 14
Conclusion................................................................................................................................ 21

Table of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure

1: Network Topology........................................................................................................ 5
2: Traceroute performed on Client machine to FTP server...............................................6
3: Client Routing table..................................................................................................... 7
4: Client BGP routing table.............................................................................................. 7
5: ASN3 BGP routing table............................................................................................... 8
6: ASN2 BGP routing table............................................................................................... 8
7: README file for prefix hijacking.................................................................................10
8: ASN3 BGP table after prefix hijacking........................................................................10
9: ASN2 BGP table after prefix hijacking........................................................................11
10: Traceroute for sub prefix hijack............................................................................... 11
11: FTP file from server.................................................................................................. 11
12: README file using sub prefix hijacking....................................................................12
13: ASN3 BGP routing table after sub prefix hijack........................................................12
14: ASN2 BGP routing table after sub prefix hijack........................................................13
15: Detection Algorithm [13]......................................................................................... 17
16: Reactive Detection System [1]................................................................................ 19
17: Reactive Defense Analysis [1]................................................................................. 20
18: Proactive and Reactive Defense Comparisons [1]...................................................21

Overview
The 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

Experiments
Part 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 Timeline
Tasks

Date

Tasks Completed By

BGP hijacking Proposal

March 18th,
2014

Ashish (Writer), Gaurav (Proof read), Vincent

(Proof read)

Perform BGP hijacking

March 27th,
2014

Ashish (part 1), Gaurav (part 2), Vincent (part 3)

Write DETER report

March 27th,
2014

Ashish (part 2), Gaurav (part 2), Vincent (part 3)

Compile DETER report

March 29th,
2014

Ashish (Proof read), Gaurav (Compile report),

Vincent (Proof read)

BGP Defenses Report

April 13th,
2014

Ashish (Writer), Gaurav (Proof read), Vincent

(Proof read)

BGP Defense Analysis

Comparison

April 25th,
2014

Ashish (Proof read), Gaurav (Proof read), Vincent

(Writer)

Team Meeting

May 2nd,
2014

Presentation Slides

May 4th,
2014

Attendees: Ashish, Gaurav, Vince. Discussion

about presentation specifics and detailed review
of experiment.
Ashish (Proof read), Gaurav (Writer), Vincent
(Proof read)

Compile Final Report

May 4th,
2014

Ashish (Proof read), Gaurav (Proof read), Vincent

(Compile report)

Record Experiment

May 4th,
2014

Ashish (Recorder), Gaurav (Proof read), Vincent

(Proof read)

Team Meeting

May 4th,
2014

Presentation Rehearsal by all members

Final Presentation

May 6th,
2014

Final presentation and submission of project

documents.

BGP Prefix Hijack Attacks

(DETERLAB LAB EXPERIMENT)
A. Network Topology:

Figure 1: Network Topology

The 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 the client machine and perform the following tasks:On the command
prompt run: traceroute -n 10.1.1.2 and 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 command
sjs209ak@client:~$ date;traceroute -n 10.1.1.2;date
Thu Mar 27 12:55:29 PDT 2014
traceroute 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 2014
Figure 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. Run netstat -rn and 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).
6

Executing Given Commands:

sjs209ak@client:~$ date;netstat -rn;date

Thu Mar 27 12:58:16 PDT 2014
Kernel IP routing table
Destinatio
n
Gateway
Genmask
255.255.255.
10.5.0.0
0.0.0.0
0
192.168.0.
255.255.252.
0
0.0.0.0
0
10.0.0.0
10.5.0.1
255.0.0.0
192.168.1.25
0.0.0.0
4
0.0.0.0
Thu Mar 27 12:58:16 PDT 2014

Flag
s

MSS

Window

irtt

Iface

0 eth0

U
UG

0
0

0
0

0 eth1
0 eth0

UG

0 eth1

Figure 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:

RTF_GATEWAY

Destination requires forwarding by intermediary

RTF_UP

Route usable

3. Run sudo 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";date
Thu Mar 27 12:59:50 PDT 2014
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
K>* 0.0.0.0/0 via 192.168.1.254, eth1
S>* 10.0.0.0/8 [1/0] via 10.5.0.1, eth0
C>* 10.5.0.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/22 is directly connected, eth1
Thu Mar 27 12:59:50 PDT 2014
Figure 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:
o Static/Connected routes are properly described
o Loopback address is provided in this output

4. Run ftp 10.1.1.2 and at the prompt for username type anonymous, type some
random text for password. Once you are connected to the ftp server, type get
README at the ftp prompt. After the README file finishes downloading,
logout (type exit) 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 to asn3 machine and perform the following tasks (it helps to keep a
separate terminal for each host you need to login):
Run sudo 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.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network

Next Hop

*> 10.1.0.0/16

10.3.0.2

*> 10.5.0.0/16

0.0.0.0

*> 10.6.0.0/24

10.4.0.2

Metric

LocPrf

Weight

Path
0 65002 65001 i

32768 i

Figure 5: ASN3 BGP routing table

0 65004 i

The AS path to reach the 10.1/16 network is 65002 65001 i

6. Login to asn2 machine and perform the following tasks:

Run sudo 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";date
Thu Mar 27 15:16:03 PDT 2014
BGP table version is 0, local router ID is 10.2.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network

Next Hop

Metric

LocPrf
8

Weight

Path

*>
10.1.0.0/16
*>
10.5.0.0/16
*>
10.6.0.0/24

10.2.0.1

0 65001 i

10.3.0.1

0 65003 i

10.3.0.1

0 65003 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 Hijacking

1. Run traceroute -n 10.1.1.2 and 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.
o 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. Run ftp 10.1.1.2 and at the prompt for username type anonymous, type some
random text for password. Once you are connected to the ftp server, type get
README at the ftp prompt. After the README file finishes downloading,
logout (type exit) 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:

9

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 to asn3 machine and perform the following tasks:

Run sudo 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
10

4. Login to asn2 machine and perform the following tasks:

Run sudo 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 Hijacking

1. Run traceroute -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-2

2. Run ftp 10.1.1.2 and at the prompt for username type anonymous, type some
random text for password. Once you are connected to the ftp server, type get
README at the ftp prompt. After the README file finishes downloading,
logout (type exit) and read and contents of the README file. Did the contents
of README file differ from the output in Part-2?
11

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 hijacking

3. Login to asn3 machine and perform the following tasks:

Run sudo 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

12

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 to asn2 machine and perform the following tasks:

Run sudo 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 *>

13

Attack Defenses and Analysis

1. Introduction
A 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.

14

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. Defenses
Two 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.

15

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
16

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 deaggregate 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.

17

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
18

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
19

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 allpromotion 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.

20

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 upto-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].
21

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]

Conclusion
Hijacking 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
22

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 System, 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 2006
23