2016 IEEE Canadian Conference on Electrical and Computer Engineering (CCECE)

Using Resource Public Key Infrastructure for Secure

Border Gateway Protocol
George Chang, Majid Arianezhad, and Ljiljana Trajkoviü
Simon Fraser University
Vancouver, British Columbia, Canada
{gkchang@sfu.ca, arianezhad@live.com, ljilja@cs.sfu.ca}

Abstract—Border Gateway Protocol (BGP) is a widely used II. METHODS FOR SECURING BGP
Internet routing protocol. While several security features have
been introduced and implemented to prevent attacks and address As the Internet de facto inter-domain routing protocol, BGP
routing instabilities, BGP remains vulnerable due to lack of is targeted and subjected to attacks. Over the years, security
integrity and authentication of BGP messages. BGP operations measures have been developed and methods implemented in
strongly depend on its security and attacks on BGP adversely attempts to make the Internet more secure. Several approaches
influence packet routing. Given the importance of BGP security, for enhancing BGP security have been introduced:
several approaches have been developed to enhance security of
BGP sessions. The Resource Public Key Infrastructure (RPKI), a A. Explicitly Configuring BGP Peers
specialized Public Key Infrastructure (PKI), was developed to This method explicitly sets identical configurations
help secure the Internet routing. It uses cryptographically between neighboring peer routers so that one may specify
verifiable statements to ensure that Autonomous Systems (ASes), connectivity to be limited between peers with the same
the Internet resource holders, are certifiably linked to the routing configuration. The requirement for identical configurations of
information they generate thus resulting in a reliable routing all BGP speakers prevents session establishments by routers
origin. In this paper, we describe a testbed developed for with non-matching configurations. The BGP speakers use TCP
validating route origin and present simulation results. port 179 for communication. Since BGP relies on TCP, the
inherent TCP risks and vulnerabilities also affect BGP. To
Keywords—Routing protocols; border gateway protocol; BGP
prevent attackers from spoofing BGP packets sent over TCP
security; resource public key infrastructure
and from hijacking the session, strong sequence number
I. BGP SECURITY randomization may be employed. Since the attacker would then
need to guess the sequence number of the packet for message
The Border Gateway Protocol (BGP) [1] was developed injection or modification, using strong sequence number
and designed before the Internet environment became randomization would make predicting or guessing the correct
subjected to attacks, exploits, and routing vulnerabilities. The sequence or acknowledgment (ACK) number improbable [3].
originally designed BGP lacks security countermeasures
required to prevent intentional or accidental network errors. B. Deploying BGP Session Shared Secrets
These attacks and errors cause ripple effects that propagate Using BGP session sharing for securing BGP involves
throughout the network resulting in potentially catastrophic using a shared key between both ends of the connection. This
routing disruptions. They may include modifying, deleting, key is used to compare all incoming BGP packets that contain
forging, or duplicating update messages, session hijacking, IP a 16-byte digest value created by the Message Digest 5 (MD5)
spoofing, or Distributed Denial of Service (DDoS) attacks [2]. algorithm. The recipient of the BGP packets will use its shared
Malicious attacks alone do not account for all security issues. key to compute the digest and compare it with the digest
Non-intentional and accidental errors also contribute to contained in the packet. If a mismatch occurs, the recipient
network instability. Misconfigured or faulty routers may also should not respond to the sender and will discard the packet
inject falsified information while being legitimate BGP [4], [5]. The MD5 algorithm provides authentication to packets
speakers. BGP does not have native counter-measures against and helps prevent spoofing. A shared secret key should be
these attacks. changed periodically and should be unique between peering
BGP has undergone many revisions and security sessions. While MD5 ensures integrity and prevents message
improvements. However, it still fails in preventing global duplication, it does not ensure the packet confidentiality. The
routing disruptions and traffic hijacking. Resource Public Key management of the security keys for various sessions has also
Infrastructure (RPKI), built based on the Public Key been proposed [6]. It has been observed that MD5 is
Infrastructure (PKI), formally validates route announcements “cryptographically broken and unsuitable for further use” [7].
from the originating Autonomous System (AS). The use of C. IPsec Tunneling
resource certificate ensures that only the owner (resource
holder) has the authority to advertise its routes thus preventing Internet Protocol Security (IPsec) provides strong
hijacking of the route origin. protection for message integrity and assist in prevention of
Denial of Service (DoS). IPsec ensures confidentiality of

978-1-4673-8721-7/16/$31.00 ©2016 IEEE

messages and authenticity of peer sessions. It excels in peer-to- G. Link-Local Peering
peer connectivity and communication. IPsec employs security Link-local peering employs the link local address of the
keys and security protocols such as Authentication Header neighboring routers as the IPv6 default address instead of the
(AH), Encapsulating Security Payloads (ESP), and Internet global address. This may prevent attackers from establishing a
Key Exchange (IKE) for key management [7], [9]. While IPsec connection with the router. It is considered infeasible that
is superior to MD5 in terms of its refreshed keys, it lacks in attackers will obtain these addresses thus securing session
terms of resource utilization. IPsec consumes CPU resources authentication. When using Link-local addressing, the next-hop
and introduces overhead to the router due to its requirement address is set as the global IPv6 address because the Link-local
that a link be established beforehand between peers. However, addresses are local and used exclusively within the Link-local
an attacker may still send large number of spoofing packets address' subnet. Therefore, for the router to perform global
with false authentication to a router. This results in increased routing, a route map is needed to specify a global address as
resource utilization of a router’s CPU and may slow or halt the next-hop address. Otherwise, the route would be dropped if
legitimate packets from being processed. If the router crashes, peers from other subnets could not reach the specified next-hop
the attacker accomplishes its goal. The negative impact of destination [12]. The routers may also advertise both Link-
utilizing IPsec tunnels in terms of resource consumption, local and the global addresses in the reachability information
higher maintenance, and troubleshooting difficulties made attribute. This is typical for two peers residing within one
IPsec tunneling more suitable for point-to-point connections subnet.
such as Virtual Private Networks (VPN). IPsec is not adequate
to prevent widespread attacks because it is a session-based The drawback of Link-local peering is that configurations
security method [10]. on both sides of the peering should be identical. A change in
the configuration on one side would result in routing instability
D. Configuring Loopback Addresses for BGP Peers and route flapping. Since the Link-local addresses are derived
Loopback is a virtual interface that enables connectivity of from the Media Access Card (MAC) address, hardware
a physical router to pass its inbound and outbound messages changes, such as changes in Network Interface Card (NIC),
through virtual connections. The loopback prevents the would require reconfiguration in both peers [13]. Any upgrade,
attacker from gaining the physical source address. It also keeps maintenance modification, or improvement would also need to
the TCP session alive between two routers using loopback be performed in both peers to prevent session loss or failure.
addresses when the physical connection is down. This security The additional effort in implementing Link-local peering may
method prevents the disruption and/or hijacking of TCP not yield significant improvements that could be achieved by
sessions. other security methods.
E. Controlling the Time-To-Live (TTL) of BGP Packets H. Preventing Long AS Paths and Limiting the Number of
This method, also known as the Generalized TTL-based Prefixes Received
Security Mechanism (GTSM) [11], prevents CPU overload An attacker may inflict damage to the network by
based attacks as well as other resource utilization-based prepending and sending unusually long AS paths in the update
attacks. GTSM was devised by the IETF and relies on a simple messages. These false announcements are then stored and
mechanism that TTL spoofing is considered impossible or computed by the receiving peers, wasting CPU and memory
highly unlikely. The nature of BGP peering is, in most cases, resources. Older models or ill-configured routers may be
direct or adjacent, which makes GTSM feasible. Most BGP unable to handle these long AS paths and may start to flop and
pairings are direct connections between peers and only one hop choke [14]. This results in the tear down of connections and
away. The TTL field in an IP packet decreases by one every sessions between peers. The damage continues as core routers
time the packed completes a hop. GTSM restricts the TTL field that are capable of handling the long ASes will continue to
to a value above a threshold and drops the packets that have propagate these AS paths to their peers, spreading the damage.
been through multiple hops and, thus, have a TTL value lower The flood of these updates will cause global routing instability
than the threshold. By setting the TTL field to 255 (the [15]. For example, in 2009, Supronet, a small Czech provider
maximum number in the IPv4 header), the peers will decrease announced an AS path that is 251 times longer than usual to its
the TTL value to 254. Therefore, by only accepting packets backup provider. Many older routers responded to the
that contain an inbound TTL number of 255 and above, GTSM announcement by justifying it as malformed and, thus, tore
may prevent attacks that transmit massive non-neighbor down their sessions with the speaker who propagated the
originating packets by flooding. GTSM may protect BGP from message. The result was an excessive rate of 107,780 updates
remote attackers that send spoofed messages. However, it will per-second worldwide within 8 minutes of the initial
not protect BGP against multi-hop or other type of attacks. announcement by Supronet [16]. This illustrates how a single
event may disrupt the global networking. The same effect may
F. Filtering on the Peering Interface
also be achieved using prefixes. Attacker may send large
As the best practice, filters placed on the router’s interface number of prefixes to cripple a router. The remedy is to limit
should be configured to prevent unwanted packets from either the number of prefixes or the length of AS paths that are
unknown origins. Filters should allow only neighboring peers accepted and, thus, prevent the attack of overloading a router’s
to speak. For example, filters should allow TCP port 179 available resources. Many routers may also be configured to
packets that are sourced from a neighboring peer via direct re-establish the lost session after a certain time interval to
connection. prevent the link from being lost.
I. Securing Interior Gateway Protocol (IGP) avoid errors in routing decisions. RPKI, also known as
Since BGP relies on the TCP layer, it is vital to secure the resource certification, is introduced by the Internet Engineering
transport layer. BGP relies on IGP to reach the next hop or peer Task Force (IETF) and the Secure Inter-Domain Routing
and, hence, the security of IGP is essential. Performing vital (SIDR) workings group. RPKI is built on top of the well-
countermeasures and implementing security technologies or established PKI system that relies on a public key
algorithms such as IPsec and MD5 may prevent attackers from cryptographic technique to verify identities based on digital
infiltrating and damaging the network. certificates. The certificate fields and the X.509 standard for
RPKI are described in RFC 5280 [20]. In 2011, Réseaux IP
J. Extreme Measures for Securing Communications between Européens (RIPE) launched the RPKI system that enables
BGP Peers Local Internet Registries (LIRs) to request a digital certificate
Manually setting information during router configuration for the Internet resources that they hold. Other Regional
may greatly reduce the security risks in BGP peering. Internet Registries (RIRs) then established certificate systems
Configurations such as disabling the Neighbor Discovery to validate all resources they allocate or assign [21]. The RPKI
Protocol (NDP) for IPv6 may prevent attackers from launching system may be used to certify other Internet resources.
a DoS attack [17]. Manually configuring the static IPv6 In order to participate in the route origin validation system,
addresses on the interface is much safer. It is similar to network operators need to create Route Origin Authorizations
establishing a link-local peering where one explicitly specifies (ROAs) that validates route announcements. ROAs are
the connections thus removing the NDP from configuration. cryptographical objects that verify ASes authorized to originate
This method may have hidden side effects and may result in certain address space in BGP announcements across the
additional cost and troubleshooting if routers are ill-configured. Internet. An ROA contains three elements: the authorized AS
number, the address space that an AS may originate, and the
III. BGP ROUTING OUTAGES
maximum length of the authorized address space. RPKI system
Current BGP security mechanisms do not emphasize route supports valid, invalid, or unknown route announcements
origin validation. BGP has no built-in methods to validate the maybe [22]. Network operators may perform routing decisions
origin of prefixes for route advertisements across the Internet. based on these states that indicate the status of a route.
This implies that routers are prone to rogue routing information
and will likely forward invalid addresses to other routers. A. RPKI Validators
Consequently, if a route is hijacked or wrongly advertised, Participants in RPKI may use a validator tool that retrieves
BGP would be unable to detect it and promptly react to avoid information from RIRs’ repositories to improve BGP routing
service interruption. decisions [23], [24]. The recommended tools are available
from: RIPE Network Coordination Centre (RPKI Validator),
Over the years, there have been many incidents of routing
Dragon Research Labs (rcynic Validator), and Raytheon BBN
outages [18]. Most of them involve trusting one or more transit
(RPSTIR Project). RIPE RPKI validator provides a web user
carriers that may unknowingly advertise the incorrect or
interface for viewing, configuring, querying validated ROAs,
unauthorized routing information across the Internet. One
and previewing RPKI validity state of BGP announcements
example occurred on February 24, 2008 when the Pakistan
across the Internet. RPKI-capable routers may connect to the
Telecom (AS 17557) advertised route 208.65.153.0/24 for
RIPE RPKI validator and transfer validated ROA datasets. The
YouTube (AS 36561) and hijacked the traffic. Since the /24 is
validator is preconfigured to automatically download and
a more specific route than 208.65.152.0/22 that YouTube
validate with Trust Anchor Locator (TAL) from four RIRs:
advertised, part of the Internet chose to route the traffic to
AFRINIC, APNIC, LACNIC, and RIPE. Obtaining the trust
Pakistan Telecom instead. This unauthorized global
anchor for ARIN requires accepting ARIN’s Relying Party
announcement of YouTube address space was the consequence
Agreement and then manually adding arin.tal file to the RPKI
of BGP’s transitive trust model. The Pakistan Telecom’s
validator.
(17557) main transit provider PCCW (AS 3491) simply trusted
Pakistan Telecom’s routing information and re-advertised it to The ROAs are designed to be published rather than be kept
its peers without validation. Since there was also mutual trust confidential. They are stored in repositories available to all
between PCCW (3491) and its peers through transitive trust RIRs and Internet Service Providers (ISPs). There is no
model, PCCW’s peers did not verify the route origin [19]. The authentication for ROAs because the PKI only offers
result was an outage of YouTube services for over two hours. authorization verification [25].
Although this incident may have been unintentional, it
illustrates that without adequate route origin validation, RIPE NCC provides a Java application toolset that acts as a
attackers could achieve BGP routing outages. Origin validation local cache validator. This application runs as a service and
for BGP is a mechanism that may solve security issues. It only requires a UNIX based system to operate. It includes a
employs RPKI to ensure that route advertisements are variety of components and options available to network
originated from the expected AS. operators to monitor and validate BGP routes. Application
support and training are available on the RIPE NCC webpage.
IV. RESOURCE PUBLIC KEY INFRASTRUCTURE This application was the first ARIN’s RPKI Validation tool
[26].
The most common routing errors occur when an
unauthorized holder of the address space announces a RPKI is an elegant way of ensuring resource
particular IP prefix. RPKI offers BGP origin validation to authentication, allowing peers to better understand route
announcements and make routing decisions. Easy TABLE I. SIMULATION IP ASSIGNEMNTS
implementation and maintenance makes RPKI a suitable Device Interface Prefix IP Assignment Description
measure to secure BGP. Software and online portals provided R1
ge-1/0 142.231.110.64/30 142.231.110.66
R1 router to
by the RIRs, such as ARIN and RIPE, make managing RPKI AS11105 Validator
SFU ge-1/1 142.231.110.68/30 142.231.110.70 R1 to R2
easy for valid subscribers. R2 router to
R2 AS271 ge-1/1 142.231.110.60/30 142.231.110.62
Validator
BCNET
V. SIMULATION SCENARIOS ge-1/2 142.231.110.68/30 142.231.110.69 R1 to R2
Validator to
We designed a simulation scenario as a proof of concept to eth0 Bridged network Dynamic
the Internet
investigate RPKI’s scalability. The goal was to implement the RPKI
eth1 142.231.110.64/30 142.231.110.65
Validator to
Validator R1
RPKI system with the validator tool using production RPKI
Validator to
cache server data in a virtual environment. eth2 142.231.110.60/30 142.231.110.61
R2

The simulations were conducted using Graphical Network B. Simulation Results

Simulator 3 (GNS3) [27] with the virtual machine (VM)
running Linux as the “RPKI Validator”. The VM is hosted on The simulation results were conclusive. Router R2, that
Oracle VirtualBox running Ubuntu 14.04.2 Trusty 64-bit was receiving route advertisements from R1, was able to
version image. The RPKI validator tool was installed on the identify the validity of all routes received from R1 and to
Ubuntu VM running the June 5, 2015 RIPE RPKI Validator assign localpref numbers that were previously configured on
2.2. Virtual routers were two Cisco c7200 running router R2.
Internetwork Operating System (IOS) image version 15.2 that Valid State: Route 206.12.7.0 was advertised to R2
supports RPKI. The router images were imported into GNS3 (AS 271) using an actual route validated for AS 11105. The
v.1.3.7. state has been identified as “valid” with a localpref of 110 as
A. Simulation Setup: Network Topology and Configurations configured:
The simulated network topology is shown in Figure 1. R2#show ip bgp 206.12.7.0
BGP routing table entry for 206.12.7.0/24, version 3
Path: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
11105
142.231.110.70 from 142.231.110.70 (142.231.110.70)
Origin IGP, metric 0, localpref 110, valid …
Path 68DB44CC RPKI State valid
Rx pathid: 0, tx pathid: 0x0

Invalid State: R2 (AS 271) advertised an invalid route to

R1 (AS 11105) using a randomly selected IP that was not in
the RPKI database for both ASes. The state has been identified
as “invalid” with a localpref of 90 as configured:
R1#sh ip bgp 193.175.146.0
BGP routing table entry for 193.175.146.0/24, version 0
Path: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 9
271
142.231.110.69 from 142.231.110.69 (142.231.110.69)
Origin IGP, metric 0, localpref 90, valid …
Path 682CAF34 RPKI State invalid
Figure 1: Network topology. Rx pathid: 0, tx pathid: 0

Two virtual routers labeled R1 and R2 are connected to Unknown State: R1 (AS 11105) advertised an unknown
each other and to the RPKI Validator through Ethernet route to R2 (AS 271) using a randomly selected IP that was not
connections. R1 was assigned a genuine AS number 11105 that in the RPKI database for both AS. The state has been identified
belongs to SFU while R2 was assigned BCNET’s AS 271. By as “not found” with a localpref of 100 as configured:
using these AS numbers, live data from the validator are used R2#sh ip bgp 6.0.0.0
to validate the advertised routes based on the AS numbers. The BGP routing table entry for 6.0.0.0/8, version 5
RPKI Validator requires the Internet connection to download Path: (1 available, best #1, table default)
Not advertised to any peer
the ROA resources to the VM. IP assignments used in the Refresh Epoch 10
simulation scenario are shown in Table I. 11105
142.231.110.70 from 142.231.110.70 (142.231.110.70)
Origin IGP, metric 0, localpref 100, valid …
Router configurations were completed by assigning the Path 68DB4424 RPKI State not found
rpki-loc-pref to each individual state. Both virtual routers were Rx pathid: 0, tx pathid: 0x0
configured to connect to port 8282 of the RPKI Validator to
download the ROA resources. R1 was setup to advertise to R2 The simulations illustrate that RPKI may be easily
three distinct routes with known states: valid, invalid, and implemented in deployed networks and was capable of
unknown. Router R2 then validates the route advertised by R1 downloading actual ROA resources in a virtual environment.
with live ROA data from the RPKI Validator.
 VI. DEPOLYED TESTBED SFU and BCNET have created resource certificates and
We have built a testbed with the objectives to observe the generated distinct ROA key pairs for their IP prefixes.
states of route announcements and verify the effects of routing Upon accepting ARIN’s Relying Party Agreement, ARIN’s
policies in RPKI BGP. The setup shown in Figure 2 closely TAL (ARIN’s public key) is sent to the recipient’s email
resembles the simulated network topology. Both routers are address. A network operator needs to create and save ARIN’s
connected to a local cache validator that downloads the ROA TAL. The validator service automatically loads files matching
dataset. The SFU and BCNET BGP speakers announce to each the *.tal on startup.
other globally routable prefixes 192.67.9.0/24 and
206.12.7.0/24. The testbed includes two routers and one local The RPKI validator machine has three interfaces: eth0,
cache validator. Two logical routers were instantiated using eth1, and eth2. The interface eth0 (outside interface) connects
JunOs software installed on the SFU and BCNET test the validator to the Internet. Interfaces eth1 and eth2 are
equipment. JunOs software partitions a single router into connected to the BCNET’s and the SFU’s routers, respectively.
multiple logical devices performing independent routing tasks. An important security practice is to configure firewall of the
The IP assignments for the routers and the local cache validator validator machine to accept connections from anticipated
are shown in Table II. combinations of IP addresses and port numbers. In the
deployed testbed, the validator only accepts TCP connections
from 142.231.110.62:8282 and 142.231.110.66:8282 to eth1
and eth2, respectively.
There are several connection mechanisms between virtual
routers: logical tunnel interfaces, rib-group, instance-import,
and next-table. Logical tunnels are point-to-point interfaces
that carry traffic between virtual routers. In the SFU-BCNET
testbed, logical tunnel interfaces (lt-0/2/10) were used to form
BGP peering between two virtual routers. We assigned the
actual SFU AS number (AS 11105) and BCNET AS number
(AS 271) to the logical routers, as in the simulation scenario.
Each router has a loopback interface that may be assigned
multiple IP addresses. Loopbacks were assigned invalid IP
addresses (192.168.42.1 and 192.168.42.2) that were required
to create the logical tunnel interfaces (lt-0/2/10). Moreover, in
order to announce prefixes to routers, 206.12.7.1 (SFU prefix
206.12.7.0/24 with ROA) and 192.67.9.1 (BCNET prefix
192.67.9.0/24 with ROA) were assigned to SFU and BCNET’s
Figure 2: Logical topology of the deployed testbed. loopback connection, respectively.
B. Verifying Origin Validation
TABLE II. IP ASSIGNEMNTS FOR THE SIMUALATION
RPKI commands show validation session, show validation
Device Interface Prefix IP Assignment Description statistics, and show validation database are performed on the
SFU router to
ge-0/0/0 142.231.110.64/30 142.231.110.66
Validator router to verify the routes. RPKI command output:
SFU test
192.168.42.2/32 192.168.42.2 Loopback
router tr1.vncv1> show validation session detail
lo0 SFU prefix for Session 142.231.110.61, State: up, Session index: 2
AS 11105 206.12.7.0/24 206.12.7.1
ROA Group: BCNET_VALIDATOR, Preference: 200
lt-0/2/10 142.231.110.68/30 142.231.110.70 Tunnel Local IPv4 address: 142.231.110.62, Port: 8282
BCNET router Refresh time: 300s
ge-0/0/0 142.231.110.64/30 142.231.110.66 Hold time: 900s
to Validator
192.168.42.1/32 192.168.42.1 Loopback Record Life time: 900s
R2 AS271
Serial (Full Update): 441
BCNET lo0 BCNET prefix
192.67.9.0/24 192.67.9.1 Serial (Incremental Update): 441
for ROA Session flaps: 2
ge-1/2 142.231.110.68/30 142.231.110.69 Tunnel Session uptime: 1w0d 10:11:12
Validator to Last PDU received: 00:01:29
eth0 142.231.112.0/24 142.231.112.42 outside IPv4 prefix count: 7078
interface IPv6 prefix count: 1106
RPKI
Validator to
Validator eth1 142.231.110.60/30 142.231.110.61
BCNET tr1.vncv1> show validation statistics
Validator to Total RV records: 8190
eth2 142.231.110.64/30 142.231.110.65 Total Replication RV records: 8190
SFU
Prefix entries: 7815
Origin-AS entries: 8190
A. Testbed Architecture Memory utilization: 1590149 bytes
An Ubuntu VM acts as a local cache validator. SFU and Policy origin-validation requests: 6
Valid: 2 Invalid: 2 Unknown: 2
BCNET have obtained IP resources from ARIN and have BGP import policy reevaluation notifications: 3
distinct online accounts on ARIN’s website. Each ARIN inet.0, 3 inet6.0, 0
tr1.vncv1> show validation database
account is linked to an administrator. ARIN account holders RV database for instance master
manage and certify resources, such as IPv4 and IPv6 addresses. Prefix
2.0.0.0/12-16
Origin-AS Session
3215 142.231.110.61
State
valid
Mismatch
2.0.0.0/16-16
2.1.0.0/16-16
3215 142.231.110.61
3215 142.231.110.61
valid
valid
REFERENCES
2.2.0.0/16-16 3215 142.231.110.61 valid [1] Y. Rekhter and T. Li, “A Border Gateway Protocol 4 (BGP-4),” IETF
RFC 1771, Mar. 1995.
Verification of the applied policies was performed by [2] S. Murphy, “BGP Security Vulnerabilities Analysis,” IETF RFC 4272,
setting local preferences for valid, invalid, and unknown states Jan. 2006.
to 110, 90, and 100, respectively. As shown in Figure 2, a [3] Progress Toward Security the Routing Infrastructure [Online].
rogue test logical router was installed to verify the policy of an Available: http://www.cyber.st.dhs.gov/public/CATCH/Murphy.pdf.
“invalid” state. The rogue router announced SFU’s prefix, [4] CERT Advisory CA-2001-09, “Statistical Weaknesses in TCP/IP Initial
which originated from an invalid AS (AS 4476), to the BCNET Sequence Numbers” [Online]. Available: http://www.cert.org/
advisories/CA-2001-09.html.
router. The output of show route protocol bgp validation-state
[5] A. Heffernan, “Protection of BGP Sessions via the TCP MD5 Signature
invalid and show route 206.12.7.0 statements indicate that Option,” IETF RFC 2385, Aug. 1998.
BCNET router recognized the invalid AS 4476 as expected:
[6] S. Turner and L. Chen, “Updated Security Consideration for the MD5
tr1.vncv1> show route protocol bgp validation-state valid Message-Digest and the HMAC-MD5 Algorithms,” IETF RFC 6151,
inet.0: 13 destinations, 14 routes (13 active, 0 holddown, Mar. 2011.
0 hidden)
+ = Active Route, - = Last Active, * = Both [7] M. Leech, “Key Management Consideration for the TCP MD5 Signature
Option,” IETF RFC 3562, July 2003.
206.12.7.0/24*[BGP/170] 3w6d 05:23:33, localpref 110
AS path: 11105 I, validation-state: valid
[8] C. Kaufman, “Internet Key Exchange (IKEv2) Protocol,” IETF RFC
> to 142.231.110.70 via lt-0/2/10.69 4306, Dec. 2005.
[9] S. Kent, “IP Authentication Header,” IETF RFC 4302, Dec. 2005.
tr1.vncv1> show route protocol bgp validation-state invalid [10] S. Kent, “IP Encapsulating Security Payload (ESP),” IETF RFC 4303,
inet.0: 13 destinations, 14 routes (13 active, 0 holddown,
0 hidden) Dec. 2005.
+ = Active Route, - = Last Active, * = Both [11] K. Butler, P. McDaniel, T. R. Farley, and J. Rexford, “A survey of BGP
206.12.7.0/24 [BGP/170] 3d 08:00:09, localpref 90 security issues and solutions,” IEEE Journal on Selected Areas in
AS path: 4476 I, validation-state: invalid
> to 142.231.110.66 via lt-0/3/10.65 Communications, vol. 98, no. 1, pp. 5–10, Jan. 2010.
[12] V. Gill, J. Heasley, D. Meyer, P. Savola, and C. Pignataro, “The
tr1.vncv1> show route 206.12.7.0 Generalized TTL Security Mechanism (GTSM),” IETF RFC 5082, Oct.
inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 2007.
0 hidden)
+ = Active Route, - = Last Active, * = Both [13] P. Marques, and F. Dupont, “Use of BGP-4 Multiprotocol Extensions
206.12.7.0/24*[BGP/170] 3w6d 05:27:15, localpref 110 for IPv6 Inter-Domain Routing,” IETF RFC 2545, Mar. 1999.
AS path: 11105 I, validation-state: valid
> to 142.231.110.70 via lt-0/2/10.69 [14] IPv6 Configuration [Online]. Available: http://www.cisco.com/web/
[BGP/170] 3d 08:03:15, localpref 90 about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html
AS path: 4476 I, validation-state: invalid [15] DDoS and Security Reports: The Arbor Networks Security Blog
> to 142.231.110.66 via lt-0/3/10.65
[Online]. Available: http://ddos.arbornetworks.com/2009/02/ahh-the-
ease-of-introducing-global-routing-instability/.
RPKI BGP does not preserve the authenticity and integrity [16] European Network and Information Security Agency: Good Practices in
of the AS path attribute carried in a BGP message. BGP Resilient Internet Interconnection [Online]. Available:
speakers may insert bogus routing information and, thus, may http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-
cause widespread disruption. An important future improvement infrastructure-and-services/inter-x/resilience-of-interconnections/report/.
would be to enable BGP speakers to verify that the ordering [17] Reckless Driving on the Internet [Online]. Available:
sequence of ASes in the path attribute represents the sequence http://www.renesys.com/2009/02/the-flap-heard-around-the-world/.
of ASes in the network layer reachability information (NLRI). [18] I. Gashinsky, J. Jaeggli, and W. Kumari, “Operational Neighbor
Discovery Problems,” IETF RFC 6583, Mar. 2012.
VII. CONCLUSION [19] Pakistan Hijacks YouTube [Online]. Available:
http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/.
Managing RPKI is easy with the existence of online [20] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W.
portals, software, and tools provided by the RIRs such as Polk, “Internet X.509 Public Key Infrastructure Certificate and
ARIN and RIPE. Juniper JunOs v.12.2 and Cisco fully support Certificate Revocation List (CRL) Profile,” IETF RFC 5280, May 2008.
RPKI. In order to examine the functionality of RPKI BGP, we [21] M. Lepinski and S. Kent, “An Infrastructure to Support Secure Internet
implemented a testbed using the JunOs software and RIPE Routing,” IETF RFC 6480, Feb. 2012.
RPKI validator software products. The experimental results [22] G. Huston and G. Michaelson, “Validation of Route Origination Using
illustrate` that RPKI BGP may provide protection against route the Resource Certificate Public Key Infrastructure (PKI) and Route
Origin Authorizations (ROAs),” IETF RFC 6482, Feb. 2012.
origin hijacks.
[23] R. Bush and R. Austein, “The Resource Public Key Infrastructure
ACKNOWLEDGMENT (RPKI) to Router Protocol,” IETF RFC 6810, Jan. 2013.
[24] P. Mohapatra, J. Scudder, D. Ward, R. Bush, and R. Austein, “BGP
The authors would like to acknowledge the contribution of Prefix Origin Validation,” IETF RFC 6811, Jan. 2013.
M. Hay, D. McWilliam, and M. Gregory from BCNET for [25] Resource Public Key Infrastructure (RPKI) [Online]. Available:
valuable assistance in setting up the testbed. https://www.arin.net/resources/rpki/index.html.
[26] M. Lepinski, S. Kent, and D. Kong, “A Profile for Route Origin
Authorizations (ROAs),” IETF RFC 6482, Feb. 2012.
[27] Graphic Network Simulator 3 (GNS3) [Online]. Available:
https://www.gns3.net.