1. An Investigation into the Limitations of the Border
Gateway Protocol
“Border Gateway Protocol (BGP) should be upgraded to prevent
the possibility of large quantities of network traffic from being
misdirected. The system underpins the flow of internet traffic, with
around 12,000 routers using BGP to direct traffic between
130,000 networks.”
Stephen Dugan, Network Consultant
The Networked Multimedia Research Group
University College London
Abstract
As the Internet is evolving, increased
significance is vital towards its reliability and
performance. Increased heterogeneity driven
by wireless and optical switching; and
transitions to internet telephony and
television, depend for their success on ability
of routing protocols to realize the
performance objectives.
Inter-domain routing is clearly central
to the Internet and BGP, as the only deployed
inter-domain routing protocol is the focal
point of all concerns. BGP dates back to the
time of commercialization of the Internet and
is widely deployed and maintained. BGP
works well in practice but is now evident that
it suffers from a significant set of problems
and limitations. Though equivocally
recognized that the reliability and
performance of BGP is critical to the
functioning of the Internet; it does not
however provide performance or security
guarantees.
This paper surveys two of the critical
BGP limitations, namely load balancing and
BGP security. We have tried to explore the
aforesaid limitations in the existing scenario
and the systemic and operational implications
of proposed solutions. Our study, through
this paper, not only emphasizes on the
prevailing scenario, the problems and
solutions but also calls for further
introspection.
Inter-domain Routing: The Basics
The current Internet is a decentralized
collection of computer networks from all
around the world. Each of these networks
is typically known as a domain or an
autonomous system (AS). An AS is a
network or group of networks under a
common routing policy, and managed by
a single authority. Today, the Internet is
basically the interconnection of more than
20,000 ASes[28]. Interdomain routing focuses
on the exchange of routes to allow the
transmission of packets between different
ASes using the inter-autonomous system
routing protocol, the Border Gateway
Protocol (BGP).
Load Balancing: The Scenario
Consider a network, where exists, from
one router, multiple paths to a single
destination (say, net Z) and having the
same link cost. The process by which one
can distribute the traffic equally form the
router to destination, net Z, is called Load
balancing. Load balancing can be done or
achieved either on a packet by packet basis or on
a session by session basis [21].
The significance of load balancing
in a network corresponds to better link
utilization; ignoring which one might
observe a state of either links getting
flooded or some of links not being
utilized at all. In dynamic routing protocol
like BGP, only ‘one’ best path towards the
destination is preferred and all other paths
Hamid Shahzad & Nishant Jain
Department of Microelectronics and Information Technology
Royal Institute of Technology (KTH), Stockholm

2. 2
are ignored. But in case of two or multiple
paths having the same metric value, load
balancing could be of great impact for better
utilization of given bandwidth within network.
The succeeding text in this section,
through some cases, identifies some critical
scenarios regarding load balancing in inter-
domain routing using BGP.
Consider a case in which the
customer’s AS has multiple links with the
provider’s AS. The network topology is such
that links originate from one router in the
customer’s AS and terminate at multiple
routers within the provider’s AS.
The question that attains significance
here is how to achieve load balancing over
multiple paths when sending traffic from
customer’s network if a.) all the available
paths have same metric, or b.) if all possible
paths do not have same metric?
In another scenario, multiple routers at the
customer’s end have BGP peering with
multiple routers of the same provider, thus
having more than two paths to the
destination. Again, load balancing deems
inapplicable here because of BGP’s inherent
behavior of selecting the best path from all
paths.
Similarly, in a case where a single
router of the customer’s network is
multihomed to two different service
providers, one faces the same problem. Again,
the load balancing is not practically possible
because of BGP’s behavior to use one best
path from all the paths learned through
different AS for a single destination.
Load Balancing: Preliminary Suggestions
The aforesaid scenarios indicates that need of
the hour is to formulate suggestions to induce
support for load balancing in the BGP. The
significance lies in the fact that each link in
the network should be utilized equally for the
better utilization of given bandwidth, to the
best of available capacity. Considering the
inherent behavior of BGP to select and use
one best path, practical load balancing on
multiple links seems to be a distant reality.
From the techniques available, the one
that could substantially substitute for load
balancing is load sharing. Succeeding text
explains systematic implementation of
load sharing.
Considering a situation where
customer’s AS has multiple links with that
of the provider’s, one can achieve load
balancing by storing all the possible paths
to the destination, having the same metric,
in the router routing table. Whenever the
router is asked to forward the routing
information, it selects paths alternatively
from all paths each time. So what is
advantage? And how selection of the
routes from routing table will occur? The
advantage is that all paths with the same
metric value will be available in same
routing table. Hence a mechanism, like the
round robin scheme, could be adopted to
select the paths alternatively. In this way
almost all possible paths to the destination
can be equally used without stressing or
overloading just one path. At one time
one can store up to six possible paths
towards the same destination. Load
sharing through this process will be
possible only if customer’s AS is receiving
identical updates from the fix provider.
This method will not be applicable in a
multi-provider scenario [2].
This approach can be enhanced to
adapt to a situation where the links have
different metric, for example have
different costs. The routes are first
stored in the routing table of the router
and then a policy is set for router to use
the routes based on their cost. The
approach is that router should use the
lower cost routes more than the higher
cost routes. This enhanced approach is
called unequal cost load balancing.
It is known that load balancing is
unachievable in a scenario where multiple
routers within the customer’s AS are
connected to the same provider. In this
case load sharing is achieved by the
adapting to the concept of traffic sharing.

3. 3
Here, the inter-domain routing is efficiently
implemented by defining the policies to use
one link for forwarding and receiving routing
information under normal circumstances. In
other words, the preferred link takes the lead
all the times. If this link goes down due to
some malfunction then the handle is
transferred to the other available link for
forwarding the routing updates. By doing
this, traffic sharing as well as network stability
is achieved; ensuring that multiple links
remain in use.
Furthermore, consider another
scenario where the single router from
customer’s AS is connected to two different
providers. Here the customer’s AS has
multiple outward connection. BGP’s behavior
of selecting one best path will again inhibit
load balancing and load sharing deems to be
an efficient way of attaining similar objective.
Load sharing is implemented by defining a
policy in the customer’s network. The policy
should be defined to divide all the end users
which exist in the customer’s network in two
groups. The segregation into groups should
be based on IP prefixes in a way that end
users from one group are strained to use one
link (say ISP1) and the ones from other group
use another link (say ISP2) to reach the
internet. Both incoming and outgoing traffic
for end users will flow from their allocated
link.
BGP Security: The Issues
There is an increasing level of concern
amongst many operators and researchers that
the vulnerabilities of BGP may cause large
disruptions of service under possible attacks
[26, 27]. This and subsequent sections will
focus on security related issues that exist with
the current inter-domain routing architecture
and BGP protocol.
BGP messages are subject to
modification, deletion, forgery, and replay.
The causes of these exploits are normally:
malicious intent or misconfigured BGP
routers. Spurious messages can originate from
malicious sources or accidentally
misconfigured peers.
Spurious messages originating
from malicious sources can manipulation
the data packets to introduce errors in
routing tables. There exists three primary
limitations of that contribute towards
security concerns. Firstly, BGP does not
protect the integrity, originality and source
authentication of messages. Secondly,
BGP does not validate an AS’s authority
to announce reachability information.
Lastly, BGP does not ensure the
authenticity of the path attributes
announced by an AS.
The effects of misconfiguring a
BGP router can also be similar to those of
an attack. The two types of globally
identified misconfigurations that
contribute towards BGP security are: a.)
origin misconfiguration, where a router
exports a route it should have filtered and
b.) origin misconfiguration, where an AS
accidentally injects a prefix into the global
BGP tables.
BGP security relates to three types
of communication scenarios: control
messages when setting up a session,
reachability updates and error messages
throughout the duration of a session.
Manipulation in either of the aforesaid
communication scenarios corresponds to
the following security vulnerabilities in
BGP: a.) Eavesdropping, b.) Message
Replay, c.) Message Insertion, d.) Message
Deletion, e.) Message Modification, f.)
Man-in-Middle & g.) Denial of Service.
Eavesdropping can be simply
understood as unauthorized interception
and listening to data on the wire; thus
gaining unauthorized access to sensitive
policy and route information being
forwarded between ASes.
Message replay is unauthorized
interception and recording of messages,
then resending them to the original
recipient; thus confusing the routing
protocol. Withdrawn routes can be re-

4. 4
asserted or valid ones could be withdrawn
with this type of vulnerability.
Message insertion is to insert forged
messages into a BGP session; thus
erroneously terminating BGP sessions
between peers or injecting bad routing data.
Transport protocol, TCP, provides limited
protection while BGP does not directly
protect against this.
Message deletion is to intercept and
delete a message passed between BGP peers;
thus leading to erroneous routing tables.
Message modification is to remove
messages from a BGP session, modifies them,
and reinserts them. This leads to erroneous
routing, disruption of peering relationships
thus resulting in routing failures.
Man-in-the-middle vulnerability is
similar to that of message insertion, deletion
and modification where an authorized entity
inserts itself between two peers and poses as
the sender to the receiver and vice versa. The
vulnerability exists because BGP does not
provide authentication of sources.
Denial of service vulnerability is where
the victim router is flooded with messages.
This flood the routing table with fake or
unnecessary routes, causing the table size to
exceed its capacity.
BGP Security: The Solution
To summarize, there are two main types of
security issues that exist with the current inter-
domain routing architecture and BGP
protocol. One, being the possible attacks on
the transmission of BGP messages by
legitimate routers and the other relates to the
lack of authentication in BGP.
Given that two BGP peers maintain a
BGP session over a TCP connection between
themselves, the endpoints of this TCP
connection (IP addresses and port numbers)
can often easily be determined by a distant
attacker. Furthermore, for a BGP router, a
BGP session remains up as long as BGP
messages can be exchanged over the TCP
connection. This implies that if the TCP
connection fails for any reason, the BGP
session fails as well. An attacker could
exploit this weakness by sending spoofed
TCP segments to cause a TCP connection
supporting a BGP session to fail.
One solution to address this problem
is to authenticate the TCP segments
carrying BGP messages by relying on
MD5 [28]. This forces BGP peers to
maintain a shared password. Another
solution is to use filters on the border
routers to ensure that spoofed packets
using local addresses as sources cannot
reach the network. This solution is also
applicable to ensure that a distant attacker
is not able to send spoofed BGP messages
inside an existing BGP session. These
solutions, however, do not tackle the root
of the problem and that is, how to devise
robust BGP sessions among BGP routers.
The second type of security issues
relates to the lack of authentication in
BGP where a BGP router can be
configured to advertise any IP prefix. In
any case, a BGP router should only be
allowed to advertise IP prefixes that have
been either allocated to its ASes, or
learned from legitimate peer or customer
ASes.
A first solution to improve the
security of BGP is implementation of S-
BGP. S-BGP relies on a public key
infrastructure (PKI) to allow routers to
include route verification with each
advertisement. Route verification is a
cryptographic signature confirming that
the S-BGP speaker is allowed to advertise
this path. The main concerns about S-
BGP compared to BGP are the cost
(CPU, memory, and bandwidth) of
producing, storing, and distributing
attestations, and the need to bootstrap the
PKI. Therefore, several alternate solutions
have been proposed to lower the cost of
securing BGP .
Another solution is the
implementation of Secure origin BGP
(SoBGP), which is an extension to BGP
[Ng 2002]. SoBGP adds small security

5. 5
enhancements to the existing BGP protocol
by introducing a new message type,
SECURITY. The SECURITY message is
used by BGP speakers to share certificates
and verifications. The data of these messages
are signed by the sender and allows the
receiver to validate the public key bindings,
policy, or routing data.
SoBGP provides three types of
certificates transported by the SECURITY
message: Entity, Policy and Authorization.
The entity certificate is used to verify the
existence of an source) within a routing
system. The policy certificate provides
information about an AS, which can be
used to validate its authenticity. The
authorization certificate provides information
about an AS’s authority to announce an
address. This latter certificate is used to
provide origin authentication.
An upcoming solution to secure
interdomain routing is the Interdomain Route
Validation (IRV) service. The IRV server in
an AS queries IRV servers in other ASes for
validation of received routing information.
Upon reception of an update message, a
receiving BGP speaker will request to its local
IRV service for the confirmation of accuracy
of the received information. The query
transaction is executed over a secure transport
(e.g., IPsec, TLS/SSL). Because the IRV
queries sources directly over a secure
transport, it does not incur the signature costs
of S-BGP style attestation generation or
validation.
Each AS is responsible for
determining when an update messages should
be validated. Upon deciding a message is
suspicious, the AS can query all of the
relevant ASes to verify the authenticity and
accuracy of the contents.
An origin is authenticated in IRV in a
similar manner to how sources are
authenticated.
A path is validated by querying each
AS in the path. The path is deemed valid if
the ASes acknowledge transmission of the
path. This operation may consume many
resources or take considerable time. Such
queries should be performed by an
external service.
Conclusion
In the past few years the Internet has
largely expanded in several ways. First, the
number of ASes connected to the Internet
has increased enormously Secondly, the
number of connections per AS to the
network has also significantly augmented
and thirdly, the number and diversity of
the applications supported in the Internet
have remarkably increased as well. This
tendency has increased the demands on
the scale of the network, and hence is
placing significant pressure on the
scalability and security of BGP.
Several issues remain to be solved
in the area of interdomain routing or
needs further research.
For the better utilization of link
bandwidth in the network, though this
paper describes implementation of some
existing techniques to induce the support
for load balancing, but the area is wide
open for further research to either
develop advanced and efficient load
balancing techniques or to develop an
enhanced BGP protocol with inherent
support for load balancing.
On the security side, the issues
that are being addressed today are hop
integrity, origin authentication and path
validation. Enhancements to the protocol,
such as TCP MD5 Signatures, serve to
add much needed security measures.
While moving towards more
complex solutions and public key
infrastructures seems like a lot of work
but it may be the best way to ensure that
the Internet stays reachable and secure in
the years to come.

6. 6
References
[1] Y. Rekhter and T. Li, "A Border Gateway
Protocol 4 (BGP-4)," RFC 1771, Mar. 1995.
[2] S. Halabi and D. McPherson, Internet
Routing Architectures, 2nd ed., Cisco Press,
2001.
[3] T. Bu, L. Gao, and D. Towsley, "On
Routing Table Growth," Proc. IEEE Global
Internet Symp., 2002.
[4] S. Bellovin et al., "Slowing Routing Table
Growth by Filtering Based on Address
Allocation Policies," unpublished manuscript,
June 2001.
[5] IETF Site Multihoming in IPv6 Working
Group,
http://www.ietf.org/html.charters/multi6-
charter.html.
[6] A. D. Jaggard and V. Ramachandran,
"Towards the Design of Robust Inter-domain
Routing Protocols," IEEE Network, Special
Issue on Interdomain Routing, Nov./Dec.
2005.
[7] S. Murphy, "BGP Security Vulnerabilities
Analysis," Internet draft, draft-ietf-idr-bgp-
vuln-01.txt, Oct. 2004, work in progress.
[8] A. Heffernan, "Protection of BGP
Sessions via the TCP MD5 Signature
Option," RFC 2385, Aug. 1998.
[9] R. Mahajan, D. Wetherall and T.
Anderson," Understanding BGP
Misconfigurations," ACM SIGCOMM 2002,
Aug. 2002.
[10] S. Kent, C. Lynn, and K. Seo, "Secure
Border Gateway Protocol (S-BGP)," IEEE
JSAC, Apr. 2000.
[11] G. Goodell et al., "Working Around BGP:
An Incremental Approach to Improving
Security and Accuracy of Interdomain
Routing," NDSS, Feb. 2003.
[12] W. Aiello, J. Ioannidis, and P. McDaniel,
"Origin Authentication in Interdomain
Routing," Proc. 10th ACM Conf. Comp. and
Commun. Sec., 2003.
[13] R. White, "Securing BGP through Secure
Origin BGP," IP J., Sept. 2003.
[14] Y.-C. Hu, A. Perrig, and M. Sirbu, "SPV:
Secure Path Vector Routing for Securing
BGP," ACM SIGCOMM 2004, Sept. 2004.
[15] M. Zhao, S. Smith, and D. Nicol,
"The Performance Impact of BGP
Security," IEEE Network, special issue on
Interdomain Routing, Nov./Dec. 2005.
[16] B. Huffaker et al., "Distance Metrics
in the Internet," IEEE Int'l. Telecommun.
Symp., 2002.
[17] D. Walton, A. Retana, and E. Chen,
"Advertisement of Multiple Paths in
BGP," Internet draft, draft-walton-bgp-
add-paths-04.txt, Aug. 2005, work in
progress.
[18] R. K. C. Chang and M. Lo, "Inbound
Traffic Engineering for Multihomed ASes
Using AS Path Prepending," IEEE
Network, Mar. 2005.
[19] B. Quoitin et al., "Interdomain Traffic
Engineering with Redistribution
Communities," Comp. Commun., vol. 27,
no. 4, 2004.
[20] F. Guo et al., "Experiences in
Building a Multihoming Load Balancing
System," INFOCOM 2004, 2004.
[21] Security Issues in the Border Gateway
Protocol (BGP). Evangelos Kranakis P.C.
van Oorschot Tao Wan, School of
Computer Science, Carleton University,
Ottawa, Canada.
[22] www.cisco.com (BGP e-Learning
Project).
[23] http://web.it.kth.se/~khan
[24]www.noxs.it/documentazione/multi_
homing_wp.pdf
[25]www.cisco.com/traffic-engineering
[26] RFC 1773 - Experience of BGP-4.
[27] RFC 1774 - Protocol Analysis
[28] CIDR report, http://www.cidr-
report.org. July 2005.