Hi all,
I am going to present my work about BGP security on the Beijing meeting.
Thanks for Sandra who will arranged this.
The draft is attached for your information and its abstract is pasted as
follows. Looking forward to your comments.
Abstract -
This draft proposes a mitigation scheme to protect the data delivery
in BGP during the false routing announcements. A new BGP path
attribute is defined to Decouple (DBGP) the propagation of a path and
the adoption of a path for data forwarding. DBGP does not use
suspicious paths to forward data traffic, but still propagates them
in the routing system to facilitate attack detection. It works well
with attack detection and prevention systems. DBGP can extensively
protect data delivery from routing announcements of false sub-
prefixes, false origins, false nodes and false links.
--
Mingui
INTERNET-DRAFT Mingui Zhang
Intended Status: Proposed Standard Huawei
Expires: April 24, 2011 Bin Liu
Tsinghua University
Dacheng Zhang
Huawei
Beichuan Zhang
The University of Arizona
October 21, 2010
Secure Extension of BGP by Decoupling Path Propagation and Adoption
draft-zhang-idr-decoupling-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Zhang Expires April 24, 2011 [Page 1]
INTERNET-DRAFT DBGP October 21, 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhang Expires April 24, 2011 [Page 2]
INTERNET-DRAFT DBGP October 21, 2010
Abstract
This draft proposes a mitigation scheme to protect the data delivery
in BGP during the false routing announcements. A new BGP path
attribute is defined to Decouple (DBGP) the propagation of a path and
the adoption of a path for data forwarding. DBGP does not use
suspicious paths to forward data traffic, but still propagates them
in the routing system to facilitate attack detection. It works well
with attack detection and prevention systems. DBGP can extensively
protect data delivery from routing announcements of false sub-
prefixes, false origins, false nodes and false links.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 False Routing Announcements . . . . . . . . . . . . . . . . . . 4
3.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Prevention . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Detection . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. Traditional Mitigation . . . . . . . . . . . . . . . . 6
3.3 Paradox of Blocking Suspicious Routing Updates and Attack
Detection . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. DBGP's Mitigation: Decoupling Path Propagation and Adoption . . 7
4.1 Quarantine Time . . . . . . . . . . . . . . . . . . . . . . 7
5 Protocol Descriptions . . . . . . . . . . . . . . . . . . . . . . 8
5.1 DAS_PATH Attribute Definition . . . . . . . . . . . . . . . 9
5.2 Identification of Suspicious Paths . . . . . . . . . . . . 10
5.3 Propagating Updates . . . . . . . . . . . . . . . . . . . 11
5.4 Choosing Alternative Paths . . . . . . . . . . . . . . . . 12
5.5 Releasing Quarantined Paths . . . . . . . . . . . . . . . 12
6 Security Considerations . . . . . . . . . . . . . . . . . . . 12
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . 14
Appendix A: Empirical Evaluation . . . . . . . . . . . . . . . . 14
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Zhang Expires April 24, 2011 [Page 3]
INTERNET-DRAFT DBGP October 21, 2010
1 Introduction
The false routing announcement in the global routing system is a
serious security problem that can lead to widespread service
disruptions. Existing work such as Pretty Good BGP (PGBGP)[PGBGP]
blocks suspicious routing updates to protect data delivery. However,
such an approach has the side effect of blocking the view of any
detection system at the control plane or data plane. As a result, an
attack will not be detected and operators will not be alerted to take
actions stopping the attack. This draft proposes an extension of BGP,
to solve this paradox by decoupling path propagation and adoption in
BGP (dubbed as DBGP).
2 Terminology
DBGP: Decoupling path propagation and adoption in BGP
3 False Routing Announcements
3.1 Problem
False routing announcements can be caused by either inadvertent mis-
configurations or malicious attacks. For the ease of exposition, we
use "attacker" to refer to the network (or Autonomous System, AS)
that makes the false routing announcements regardless of the
intention. Based on which part of the routing path is false, such
announcements can be classified into five types, each of which has
different severity:
o Prefix origin: The attacker originates someone else's prefix.
Depending on where a network is in the Internet topology, some
will choose paths leading to the true origin and some will
choose paths leading to the false origin.
o Intermediate node: The attacker does not forge the prefix or
its origin, but inserts itself into the path as an intermediate
AS. Similar to the case of false origin, some networks will
choose the correct paths and some the false paths. But usually
fewer networks will choose the false path since it is longer
than that of false origin attack.
o Intermediate link: The attacker forges a new link to bypass
some of the ASes to get a shorter path. The shortened path is
expected to attract more networks' traffic.
o Sub-prefix: The attacker originates a sub-prefix of someone
else's prefix. Due to the longest match in routing lookup, a
false sub-prefix will win over the original prefix. Thus, all
Zhang Expires April 24, 2011 [Page 4]
INTERNET-DRAFT DBGP October 21, 2010
traffic destined to the sub-prefix range will be forwarded to
the attacker.
o Super-prefix: Theoretically the attacker can also announce a
false super-prefix, but that will not attract any traffic
unless part of the prefix range is unused by the real owner, in
which case it is equivalent to announcing a false origin of the
unused prefix range.
3.2 Countermeasures
The current strategies proposed for the problem of false
announcements fall in three categories: prevention, detection and
mitigation.
3.2.1 Prevention
Prevention schemes (e.g., [SBGP], [SoBGP], and [SPV]) use
cryptographic mechanisms to protect the routing updates and let
routers reject any forged announcement. Unfortunately no prevention
scheme has seen much deployment on the Internet due to the lack of
incentives for those first movers. Since crypto-based schemes add
significant computational load to routers and require upgrade on
software or hardware, individual ISPs need to see immediate benefits
to justify the deployment. On the current Internet, however, the
first mover's routing announcements will be accepted by other
networks without authentication, and adding authentication does not
bring any immediate benefit.
3.2.2 Detection
The representative detection systems proposed in recent years include
[Cyclops], [PHAS], [MyASN], [IAR], [iSPY], [NWatch], [OList], and
[LWeight]. Such systems are designed to detect false routing by
examining routing updates, probing data paths, cross-checking with
registry databases, or a combination of these techniques. Once a
false routing case is detected, the owner of the prefix will be
notified, and it is expected that the owner will take actions to
resolve the problem, which, in today's Internet, usually involves
contacting the offending network or its upstream provider to stop the
false routing announcements. This process of detection, notification
and resolution takes time, ranging from an hour to a day in some past
incidents and varying from network to network [NWatch][RIPE]. In the
meantime, the damage to data traffic has already been made and
malicious attackers may have already achieved their objectives.
Zhang Expires April 24, 2011 [Page 5]
INTERNET-DRAFT DBGP October 21, 2010
3.2.3. Traditional Mitigation
A mitigation schemes attempts to protect the data traffic while an
attack is going on. The common approach is to somehow identify
abnormal routing updates and block them. As proposed in [PGBGP] and
[PGBGP++], a router can examine the content of incoming updates. If
an AS path contains unexpected prefix origin or links, it will be
suppressed from propagating for a period of time to wait for the
network operator's validation. The length of the time is configurable
by the network operators. Instead, an alternative path (via trusted
prefix origin and links) will be employed for data delivery in the
suppression period. After this period,if the path is not proved to be
illegal, the router will adopt and announce the new path. PGBGP gives
operators certain reaction time to resolve potential false
announcements while protecting data delivery in the meantime. When a
real attack is detected and resolved, the corresponding false
announcement will be withdrawn from the routing system, whereas
legitimate announcement will stay in the routing system and
eventually be accepted.
But blocking false routing announcements can get in the way of
detection systems. For instance, on September 22, 2008, a Russian ISP
AS8997 hijacked a large number of prefixes as it leaked an entire
table [ASN8997]. However, since the upstream ISP of AS8997 blocked
the routing updates, detection systems such as MyASN and IAR did not
pick up this incident. The attack mainly affected ISPs and users
within Russia but largely went unnoticed by prefix owners.
Each existing solution has its drawbacks, and none is sufficiently
effective by itself. The future of the Internet probably will have
several different solutions at the same time, complementary to each
other, forming a multi-line defense to protect routing and data
delivery before, during, and after attacks.
3.3 Paradox of Blocking Suspicious Routing Updates and Attack Detection
It has been realized that a mitigation mechanism and a detection
system that complement each other well can be integrated into an
effective routing defense solution. For instance, the mitigation
mechanism can help the detection system to confine the damage caused
by an attack, as the affected data traffic may be vulnerable for
hours before the attack can be actually detected by the detection
mechanism and be eventually stopped. Also, the mitigation mechanism
can also obtain benefit from the detection system because a
mitigation mechanism normally cannot identity false routing
information accurately with its limited knowledge, resource and time.
The output from the detection system can be used to correct the many
false positives generated by the mitigation mechanism and also inform
Zhang Expires April 24, 2011 [Page 6]
INTERNET-DRAFT DBGP October 21, 2010
the prefix owner to resolve the attack.
However, there is a dilemma: the mitigation mechanism tries to render
the attack ineffective while the detection system needs the attack to
be effective in order to detect it.
4. DBGP's Mitigation: Decoupling Path Propagation and Adoption
In order to solve the dilemma mentioned in Section 3.3, this document
proposes a solution which decouples path propagation and path
adoption. In current BGP, the path a router adopts for data
forwarding is the same path being propagated to neighbors. As a
consequence, upon receiving a suspicious path, a router has to either
accept it (no mitigation but good detection) or reject it (good
mitigation but no detection).
The basic idea of this solution is to extend BGP so that a router can
use trusted paths for data forwarding and can also inform its
neighbor routers about the suspicious path. In this way, the data
traffic is protected while the false routing announcements are being
propagated and will likely be monitored by the detection system. In
order to achieve this, a new BGP attribute, DAS_PATH, is defined in
Section 5 to transport suspicious path information. Additionally,
based on historical operating experiences, a false routing
announcement can be detected and corrected in a certain period (e.g.,
one day) after it is launched, and so an announcement will be trusted
if it is not withdrawn in a pre-defined period.
4.1 Quarantine Time
In mitigation schemes, when a new path is identified as a suspicious
one, it will be quarantined (or blocked) from being used for a period
of time, which is call the quarantine time and noted as T_q.
A router MAY determine the quarantine time itself. Assume there are
two routers, R1 and R2. R1 is the downstream of R2, and the
quarantine time of R1 and R2 is T1 and T2 respectively. The
suspicious path is PATH at R1. There are two possibilities.
o T1 is shorter than T2. When T1 expires, PATH becomes trusted by
R1 and R1 begins to use it for data delivery. R1 will announce
R1-PATH as a legitimate AS path to R2. However, at this time,
the path R1-PATH is still being quarantined by R2.
o T1 is longer than T2. When T2 expires, R1-PATH becomes trusted
by R2. However, R2 can not use this path for data delivery as
R1 has not announced R1-PATH as an AS path. It will be cached
in the Adj-RIBs-In until the downstream router R1 has announced
Zhang Expires April 24, 2011 [Page 7]
INTERNET-DRAFT DBGP October 21, 2010
it as an AS path when T1 expires.
5 Protocol Descriptions
Take Figure 5.1 for example. A, B, C, and O are DBGP routers residing
in different ASes, , X is the attacker and p is the prefix of
interest. Before the attack, the preferred path for traffic is ABCO.
Here, we use the notation "R1R2...Rn-p" to denote the AS path which
is destined to prefix "p" via routers R1, R2, ..., Rn. When X makes a
false announcement of X-p to B, B will regard this new path as
suspicious because it would divert traffic to an AS(X) that
previously was not on the data path (BCO). B will store the
suspicious path in its Adj-RIBs-In (The routing tables of an AS
router is comprised of three sub-tables: Adj-RIBs-In, Loc-RIB and
Adj-RIBs-Out [BGP4]), but keep using the existing path in its Loc-RIB
for data forwarding. At the same time, B re-announces its path (BCO)
in an update message to A, and encapsulates the new, suspicious path
(BX) as an optional transitive attribute which is defined in Section
5.1. After receiving the update message, router A learns this
suspicious path, stores it, and propagates it further to its
neighbors using the optional attribute the same way. Therefore, the
suspicious path is propagated to the Internet while not adopted for
data forwarding. This approach enable the detection systems to
intercept the suspicious path and notify the prefix owner to take
actions. Once the attack is stopped, the false announcements will be
withdrawn from the routing system, i.e., deleted or replaced in the
Adj-RIBs-In of the involved routers. However, a router realizes that
the quarantine time has been expired and the suspicious path is still
in the Adj-RIBs-In, the router regards the path as a legitimate one.
Hence the DBGP router will install the path in its Loc-RIB for data
forwarding and re-announce the path using the regular ASPATH
attribute in the update message. For example, if BX-p has been
validated as legitimate, B will announce it to A as its AS_PATH. The
rest of this section will discuss the design details in new BGP
attribute definition, identifying suspicious paths, choosing
alternative paths for data forwarding, propagating the paths, and
releasing quarantined paths.
[X]->p
^
|
[A]->[B]->[C]->[O]-p
Figure 5.1: Attack Example 1
The rest of this section will discuss the design details in the
definition of the new DAS_PATH Attribute, identifying suspicious
Zhang Expires April 24, 2011 [Page 8]
INTERNET-DRAFT DBGP October 21, 2010
paths, choosing alternative paths for data forwarding, propagating
the paths, and releasing quarantined paths.
5.1 DAS_PATH Attribute Definition
+----------------------------------+
| Attribute Type (2 octets) |
+----------------------------------+
| Attribute Length (1 or 2 octets) |
+------------------------------------------------------------------+
| Attribute Value (variable length) |
+------------------------------------------------------------------+
Figure 5.2: The DAS_PATH Attribute
DAS_PATH (Decoupled AS_PATH) is defined as a new optional transitive
Path Attribute (Figure 5.2) to be included in BGP's UPDATE message.
The first bit of the Attribute Type is set (1), therefore the
attribute is optional. The second bit of Attribute Type is set (1),
therefore the attribute is transitive and SHOULD be passed on to
other BGP peers. The third and fourth bits are Partial bit and
Extended Length bit respectively, which has already been defined in
[BGP4]. The Attribute Type code is assigned by the IANA (Internet
Assigned Numbers Authority). The definition of Attribute Length is
the same as that in [BGP4].
The Attribute Value is composed of a sequence of DAS path segments.
Each DAS path segment is encoded as a triple <path segment type, path
segment length, path segment value>.
The path segment type is a 1-octet field with the following two
allowable values:
Value Segment Type
1 DAS_SET unordered set of ASs a route in the
UPDATE message has traversed
2 DAS_SEQUENCE ordered set of ASs a route in the
UPDATE message has traversed
The path segment length is a 1-octet long field containing the number
of ASs in the path segment value field.
The path segment value field contains one or more AS numbers, each
encoded as a 2-octets long field.
When a DAS_PATH is propagated across the network, the operations on
DAS_PATH follows the well-known AS_PATH attribute only that DAS_PATH
Zhang Expires April 24, 2011 [Page 9]
INTERNET-DRAFT DBGP October 21, 2010
is non-mandatory. If a router which does not deploy DBGP receives the
update messages containing DAS_PATH attribute, i.e., does not
understand this attribute, it will just pass it on to the next
router. If its downstream router is a DBGP router, it will be able to
pick up the information from this attribute and continue DBGP
operations. Therefore DBGP can be incrementally deployed over the
Internet.
5.2 Identification of Suspicious Paths
For a given prefix p, a path is trusted if it has been staying in the
Adj-RIBs-In continuously for the required quarantine time, T_q. All
the nodes, links, and origins that appear in trusted paths are
trusted components, and the set of them is denoted by trusted(p).
This set of trusted components is derived from current contents of
all Adj-RIBs-In without using a database to store historical
information like PGBGP does. Nodes, links, and origins that do not
belong to trusted(p) are said to be suspicious components for this
particular prefix p. A new path is suspicious if it contains any
suspicious component for its prefix. However, not all suspicious
paths need to be explicitly quarantined. DBGP quarantines paths that
satisfy the following condition:
o A new path is quarantined if and only if it is suspicious, more
preferred than other alternative paths, and contains an AS that
is not in the current data forwarding path.
If the new path is not better than alternative paths, it will not be
able to divert any traffic. One may suggest that the attacker can
first announce a less preferred path so that DBGP routers will take
it as a backup path without suspicion, and then make the primary path
fail to trick the router to use the false backup path. But in this
case, if the attacker has the control of the primary path, it can
already get the traffic without doing this. If the attacker does not
have control of the primary path, it will not know when the primary
path may fail and which backup path the router will choose, thus the
attack will not be effective.
If the new path does not introduce any new AS on the data path, it is
not quarantined since it does not divert any traffic. In Figure 5.3,
when X launches an attack by announcing X-p, this path is not
quarantined by B since B already sends its traffic to X. B will
accept this path and announces it to A. Assuming ABX-p is more
preferred than ACO-p, A will quarantine ABX-p since this new path
would divert A's traffic to a new place, AS X, and X is a suspicious
origin to A.
To reduce the potential false positives in quarantining paths, we
Zhang Expires April 24, 2011 [Page 10]
INTERNET-DRAFT DBGP October 21, 2010
introduce an optimization rule. If the current best path is replaced
by a suspicious path (i.e., the same neighbor that sent the best path
previously sends another path to replace it), then the current best
path is cached for a short time period. This rule is used to
accommodate some unstable prefixes, which may get announced and
withdrawn or oscillate between two paths frequently. With this rule,
quick re-announcement of a path will not be treated as suspicious.
Previous measurement work has shown that (1) most prefixes are
stable, and only a small number of prefixes are very unstable; (2)
the most popular prefixes are stable; and (3) the most preferred
paths are being used by routers for most of the time
[BGPpop][Stable][BGPHA]. Therefore, DBGP's criterion for suspicious
paths will not generate excessive false positives in reality. The
majority of the rest prefixes is only suspicious infrequently.
+---------------+
| |
| v
[A]->[B]->[X]->[C]->[O]-p
|
p
Figure 5.3: Attack Example 2
5.3 Propagating Updates
DBGP uses the new BGP attribute, DAS_PATH, to carry the suspicious
path in updates. In certain cases DBGP update may need to carry
multiple DAS_PATHs. For example, in Figure 5.4, assume C does not
deploy DBGP and accepts the false announcement of X-p. When B
receives BCX-p, B quarantines this new path and switches to its
backup BDO-p. The update from B to A will have BDO as the AS_PATH,
and BCX as the DAS_PATH attribute. However, since BDO is suspicious
to A as well, A will quarantine BDO and switch to AEFO. Thus the
update from A will contain two DAS_PATHs: ABCX and ABDO. Whether an
update contains multiple DAS_PATHs depends on the topology and
routing policy. In the worst case, the number of DAS_PATH in an
update is the same as the AS hop count of the AS_PATH. Given AS e 10
hops, we do not expect this will make DBGP message too large and it
is confirmed in our simulations.
Zhang Expires April 24, 2011 [Page 11]
INTERNET-DRAFT DBGP October 21, 2010
[X]->p
^
|
[A]->[B]->[C]->[O]-p
| | ^
| | /|
| +-->[D]-+ |
| |
+------->[E]->[F]
Figure 5.4: Attack Example 3
5.4 Choosing Alternative Paths
When a new path is the most preferred but suspicious, DBGP routers
will use an alternative path for data delivery. The question is which
alternative path to be chosen. First, if the existing path that is
being used for data forwarding is still the best, then the router can
stick to that path without any changes. Second, if the existing path
in use will have been replaced by the suspicious path, then the
router needs to pick an alternative. For example, in Figure 5.4,
suppose C does not deploy DBGP and blindly accepts the false
announcement X-p. B's existing path BCO-p will be replaced by a
suspicious path BCX-p, therefore B needs to temporarily switch to a
backup path BDO-p from its Adj-RIBs-In. Third, if there is no
alternative path or all alternative paths are labeled as suspicious,
then the router err on data delivery by adopting a suspicious path to
forward packets.
5.5 Releasing Quarantined Paths
If the quarantined paths are false announcements, it is likely that
within T_q, the attack will be stopped and these paths being
withdrawn from the routing system. In this case, there is no explicit
release of the quarantined path. Just the upstream router will send
an update with empty DAS_PATH attribute. If T_q has passed and the
quarantined path is still in the Adj-RIBs-In, then it is more likely
that this is a legitimate path. The router will treat the path as a
regular path and make it go through the path selection process. If
the path turns out to be the most preferred one, it will be used for
data forwarding and trigger routing updates to neighbor routers.
6 Security Considerations
The entire document is about security consideration.
7 IANA Considerations
Zhang Expires April 24, 2011 [Page 12]
INTERNET-DRAFT DBGP October 21, 2010
The attribute type code of DAS_PATH should be assigned by the IANA,
which identifies the attribute uniquely from all others.
8 References
8.1 Normative References
[PGBGP] J. Karlin, S. Forrest, and J. Rexford, "Pretty Good BGP:
Improving BGP by Cautiously Adopting Routes," in
Proceedings of IEEE ICNP, 2006.
[SBGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (SBGP)," IEEE Journal on Selected Areas in
Communications, vol. 18, no. 4, pp. 582-592, 2000.
[Cyclops] Y.-J. Chi, R. Olivera, and L. Zhang, "Cyclops: the as-
level connectivity observatory," SIGCOMM Comput. Commun.
Rev., vol. 38, no. 5, pp. 5-16, 2008.
[PHAS] M. Lad, D. Massey, D. Pei, B. Zhang, and L. Zhang, "PHAS:
A Prefix Hijack Alert System," in 15th USENIX Security
Symposium, 2006, pp.153-166.
[MyASN] "RIPE myASN System," http://www.ris.ripe.net/myasn.html.
[IAR] [Online]. Available: http://iar.cs.unm.edu/
[iSPY] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, and R. Bush,
"iSPY: Detecting IP Prefix Hijacking on My Own," in
Proceedings of ACM SIGCOMM, 2008.
[NWatch] G. Siganos and M. Faloutsos, "Neighborhood Watch for
Internet Routing: Can We Improve the Robustness of
Internet Routing Today?" in Proceedings of IEEE INFOCOM,
2007.
[Olist] X. Zhao, D. Pei, L. Wang, D. Massey, A. Mankin, S. Wu,
and L. Zhang,"Dection of Invalid Routing Announcement in
the Internet," in Proceedings of the IEEE DSN, June 2002.
[LWeight] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis, "A
Light-weight Distributed Scheme for Detecting IP Prefix
Hijacks in Real-time," in Proceedings of ACM SIGCOMM,
2007.
[SoBGP] J. Ng, "Extensions to BGP to Support Secure Origin BGP,"
April 2004, ftp://ftp-eng.cisco.com/sobgp/drafts/draft-
ng-sobgp-bgp-extensions-02.txt.
[SPV] Y.-C. Hu, A. Perrig, and M. Sirbu, "SPV: Secure Path
Vector Routing for Securing BGP," in Proceedings of ACM
SIGCOMM, 2004.
[RIPE] [Online]. Available: http://www.ripe.net/news/study-
youtubehijacking.html
[ASN8997] "Prefix hijack by ASN 8997." [Online]. Available:
http://www.merit.edu/mail.archives/nanog/2008-
09/msg00704.html
[BGPpop] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, "BGP Routing
Stability of Popular Destinations," in Proceedings of ACM
Zhang Expires April 24, 2011 [Page 13]
INTERNET-DRAFT DBGP October 21, 2010
IMC 2002, pp. 197-202.
[Stable] K. Butler, P. McDaniel, and W. Aiello, "Optimizing BGP
Security by Exploiting Path Stability," in Proceedings of
ACM CCS, Alexandria, VA, United States, 2006, pp. 298-
310.
[BGPHA] R. V. Oliveira, R. Izhak-Ratzin, B. Zhang, and L. Zhang,
"Measurement of Highly Active Prefixes in BGP," in
Proceedings of IEEE Globecom,2005.
[BGP4] J. W. Stewart, BGP4: Inter-Domain Routing in the
Internet. Boston,MA, USA: Addison-Wesley Longman
Publishing Co., Inc., 1998.
8.2 Informative References
Appendix A: Empirical Evaluation
The following aspects of DBGP are tested on the SSFNet-2.0 simulation
platform which has implemented BGP4.
o The ability to counter different types of attacks
o The ability to rectify the false positives
o The memory and message overhead
The evaluation proves that DBGP can be used to mitigate all types of
attacks. Compared with previous mitigation approaches [PGBGP], it
reduces the delay of legitimate announcements significantly, only
incurs a small amount of messages and memory overhead.
Author's Addresses
Mingui Zhang
Huawei Technologies Co.,Ltd
HuaWei Building, No.3 Xinxi Rd., Shang-Di
Information Industry Base, Hai-Dian District,
Beijing, 100085 P.R. China
Email: [email protected]
Bin Liu
Tsinghua University
East Main Building RM9-416
Tsinghua University, Hai-Dian District,
Beijing, 100084 P.R. China
Email: [email protected]
Dacheng Zhang
Huawei Technologies Co.,Ltd
HuaWei Building, No.3 Xinxi Rd., Shang-Di
Zhang Expires April 24, 2011 [Page 14]
INTERNET-DRAFT DBGP October 21, 2010
Information Industry Base, Hai-Dian District,
Beijing, 100085 P.R. China
Email: [email protected]
Beichuan Zhang
University of Arizona
Computer Science Department,
The University of Arizona
Tucson, AZ 85721 U.S.A.
Email: [email protected]
Zhang Expires April 24, 2011 [Page 15]
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
