[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
INTERNET-DRAFT Mingui Zhang
Intended Status: Proposed Standard Huawei
Expires: September 15, 2011 Bin Liu
Tsinghua University
Dacheng Zhang
Huawei
Beichuan Zhang
The University of Arizona
March 14, 2011
Secure Extension of BGP by Decoupling Path Propagation and Adoption
draft-zhang-idr-decoupling-02
Abstract
This draft proposes a novel mitigation scheme to protect the inter-
domain data delivery during false routing announcements. A new path
attribute is defined to Decouple propagation of a path and adoption
of a path for data forwarding in BGP (DBGP). DBGP does not use
suspicious paths for data forwarding, but still propagates them in
the routing system to facilitate attack detection. It can extensively
protect data delivery from routing announcements of false sub-
prefixes, false origins, false nodes and false links, and works well
with ongoing attack detection and prevention systems.
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
Acknowledgements
Zhang Expires September 15, 2011 [Page 1]
INTERNET-DRAFT DBGP March 14, 2011
The helpful comments of the following are hereby acknowledged, in
alphabetic order: Alvaro Retana, Xiaohu Xu.
Copyright Notice
Copyright (c) 2011 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
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.
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 . . . . . . . . . . . . . . . . 7
3.3 Paradox of Blocking Suspicious Updates and Attack
Detection . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. DBGP's Mitigation: Decoupling Path Propagation and Adoption . . 8
4.1 Quarantine Time . . . . . . . . . . . . . . . . . . . . . . 8
5 Protocol Descriptions . . . . . . . . . . . . . . . . . . . . . . 9
5.1 DAS_PATH Attribute . . . . . . . . . . . . . . . . . . . . 10
5.2 Identification of Suspicious Paths . . . . . . . . . . . . 11
5.3 Propagating DAS_PATHs with Updates . . . . . . . . . . . . 12
5.4 Choosing Alternative Paths . . . . . . . . . . . . . . . . 13
5.5 Releasing Quarantined Paths . . . . . . . . . . . . . . . 14
6 Clarifications . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Individual Historical Database . . . . . . . . . . . . . . 14
6.2 Difference from "add-path" . . . . . . . . . . . . . . . . 14
6.3 Detection Facilitation . . . . . . . . . . . . . . . . . . 14
6.4 Cooperation with Prevention . . . . . . . . . . . . . . . 15
7 Security Considerations . . . . . . . . . . . . . . . . . . . 15
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . 15
Zhang Expires September 15, 2011 [Page 2]
INTERNET-DRAFT DBGP March 14, 2011
9.2 Informative References . . . . . . . . . . . . . . . . . 16
Appendix A: Empirical Evaluation . . . . . . . . . . . . . . . . 17
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Zhang Expires September 15, 2011 [Page 3]
INTERNET-DRAFT DBGP March 14, 2011
1 Introduction
False routing announcements cause serious security issues to the
inter-domain routing system, which can lead to widespread service
disruptions. A special case is prefix hijacking, in which a network
announces an IP prefix that belongs to another network. Existing
works such as Pretty Good BGP (PGBGP)[PGBGP] block suspicious routing
updates to protect data delivery. However, such an approach has the
side effect of blocking the view of detection systems at the control
plane and data plane. As a result, an attack will not be detected,
and operators will not be alerted to take actions to stop the attack.
This draft proposes an extension of BGP, to solve this paradox by
decoupling path propagation and adoption in BGP.
In current BGP, the path a router adopts for data forwarding is the
same path being propagated to neighbors. That is why 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). Our
idea is for a router to use trusted paths for data forwarding, but
still inform its neighbors about the suspicious path. The suspicious
paths will be carried in an optional transitive attribute in BGP
updates, while the routers still use trusted paths for data
forwarding. This way the data traffic is protected while false
routing announcements are being propagated to detection systems.
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
Zhang Expires September 15, 2011 [Page 4]
INTERNET-DRAFT DBGP March 14, 2011
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
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.
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
Zhang Expires September 15, 2011 [Page 5]
INTERNET-DRAFT DBGP March 14, 2011
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 September 15, 2011 [Page 6]
INTERNET-DRAFT DBGP March 14, 2011
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 this 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. In future, there may be several different
solutions deployed on the Internet 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 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 September 15, 2011 [Page 7]
INTERNET-DRAFT DBGP March 14, 2011
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
The suspicious paths are serially blocked hop by hop for validation
in traditional mitigation schemes, which gets in the way of detection
systems. In order to solve this dilemma, this document proposes a
solution which decouples path propagation and path adoption. The
basic idea of this solution is to extend BGP's update message with a
new optional transitive path attribute so that a router can inform
its neighbor routers about the suspicious path and meanwhile the
router uses another trusted path for data forwarding. In order to
achieve this, a new BGP attribute, DAS_PATH, is defined in Section 5.
Compared to the traditional mitigation schemes, the propagation of
suspicious paths through DAS_PATHs in DBGP enables the parallel
validation, which accelerates the adoption process of suspected
legitimate paths (the false positive).
4.1 Quarantine Time
Based on 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. Therefore, 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 called the quarantine time and noted as T_q. If a new path has
stayed in a router's Adj-RIBs-In for more than T_q, it will be
trusted by this router. If this path is the most preferred from the
Adj-RIBs-In, the router will use this path for data delivery and
announce this path to its neighbors.
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 cannot use this path for data delivery as R1
Zhang Expires September 15, 2011 [Page 8]
INTERNET-DRAFT DBGP March 14, 2011
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 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 in 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
Zhang Expires September 15, 2011 [Page 9]
INTERNET-DRAFT DBGP March 14, 2011
definition of the new DAS_PATH Attribute, identifying suspicious
paths, choosing alternative paths for data forwarding, propagating
the paths, and releasing quarantined paths.
5.1 DAS_PATH Attribute
+-+-+-+-+-+-+-+-+
| Attribute Type| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (1 or 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 messages.
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 field is 1-octet long field and contains 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
Zhang Expires September 15, 2011 [Page 10]
INTERNET-DRAFT DBGP March 14, 2011
DAS_PATH follows the well-known AS_PATH attribute only that DAS_PATH
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.
Zhang Expires September 15, 2011 [Page 11]
INTERNET-DRAFT DBGP March 14, 2011
To reduce the potential false positives in quarantining paths, we
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 DAS_PATHs with Updates
DBGP uses the new BGP attribute, DAS_PATH, to carry a suspicious path
in an update. In certain cases DBGP router may need to select a
DAS_PATH from multiple ones to announce. 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 can contain either ABCX or ABDO. A router's
neighbors may simultaneously send updates containing the DAS_PATH to
it, which also makes the router have multiple DAS_PATHs to choose.
There are two possible choices for DBGP implementations.
1. Dominate a router to select the best DAS_PATH from the
multiple ones to announce, which is similar to the traditional
AS_PATH selection process.
2. Encapsulate all the DAS_PATH attributes in tandem and sort
them by their priorities. The priorities are determined
according to the rules used in the AS_PATH selection process.
Zhang Expires September 15, 2011 [Page 12]
INTERNET-DRAFT DBGP March 14, 2011
The first rule works well due to the following two facts. First,
during attacks, the best DAS_PATH is most likely the bogus path
aiming to attract data traffic. Second, during false positives, the
best DAS_PATH will most likely become the best AS_PATH when the
quarantine time ends.
The second rule allows an AS router to provide more information to
its upstream, which is helpful for diagnose and correctness of
attacks. Moreover, the announcement of multiple DAS_PATHs MAY help to
reduce the convergence time. Take Figure 5.4 for example, A announces
two DAS_PATHs, i.e., ABDO-p and ABCX-p, to its upstream node, says U.
When U receives the additional DAS_APTH: ABDO-p, it will begin the
validation process of this suspicious path. After A determines that
BDO-p is legitimate and installs it to its Loc-RIB, the validation
process MAY have been finished, therefore U can immediately start to
use ABDO-p.
For the second rule, the number of DAS_PATHs in an update depends on
the topology and policy of the network. Generally speaking, the
number of DAS_PATHs in an update increases with the AS hop count of
the AS_PATH. However, given AS paths are usually 4 to 5 hops and
rarely goes to more than 10 hops, we do not expect the announcement
of multiple DAS_PATHs will make DBGP message too large.
[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
Zhang Expires September 15, 2011 [Page 13]
INTERNET-DRAFT DBGP March 14, 2011
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 Clarifications
6.1 Individual Historical Database
When DBGP is implemented in an AS router, the router does not have to
purchase additional memory to store the trusted paths as that in
[PGBGP]. By default, a DBGP router uses the simple rules defined in
Section 5.2 to filter suspected components of an AS path based on the
information stored in its Adj-RIBs-In. All a router need to do is to
add a new column to its Adj-RIBs-In to record the elapse time after
an AS path entered a Adj-RIB-In.
6.2 Difference from "add-path"
DBGP solution is different from the ongoing work of advertising
multiple BGP paths in [add-path] where AS routers are also allowed to
export multiple AS paths in one update. All advertised AS paths are
available to upstream AS routers in [add-path]. Despite that DBGP
allows multiple paths to be advertised in one update, except the AS
path, all the other paths are actually unavailable. In other words,
these paths only remain in Adj-RIBs-In of the AS router. They will
not be put into either the Loc-RIB or Adj-RIBs-Out.
6.3 Detection Facilitation
Traditional mitigation mechanisms block the propagation of suspicious
paths, which undermines the effectiveness of detection systems. DBGP
is proposed to address this shortage. In DBGP, the data traffic is
protected while the false routing announcements are spread out to be
monitored by detection systems. If the first rule in Section 5.4 is
Zhang Expires September 15, 2011 [Page 14]
INTERNET-DRAFT DBGP March 14, 2011
adopted, the capacity of propagating suspicious paths in DBGP is the
same as that in BGP. If the second rule is adopted, this capacity is
enhanced by DBGP instead.
6.4 Cooperation with Prevention
As a mitigation scheme, DBGP routers validate AS paths based on the
limited information stored in local Adj-RIBs-In. This would cause
some legitimate paths to be identified as suspicious and blocked from
being used for data delivery (high false positive). If a down stream
router would like their paths be adopted quickly rather than be
suspected, it can include certificates in the update messages. For
example, if AS routers adopt the solution in [pfx-va], the AS number
claiming to originate an address prefix will be validated by the
prefix holder. The authorized origin will not be suspected by DBGP
routers. Further, if the validation can cover the whole AS path, all
kinds of attacks that DBGP is trying to cope with SHOULD be prevented
in the first place. In all, the deployment of DBGP actually creates
the incentive for deploying prevention systems.
7 Security Considerations
The entire document is about security consideration.
8 IANA Considerations
The attribute type code of DAS_PATH should be assigned by the IANA,
which identifies the attribute uniquely from all others.
9 References
9.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.
[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
Zhang Expires September 15, 2011 [Page 15]
INTERNET-DRAFT DBGP March 14, 2011
SIGCOMM, 2004.
[BGP4] J. W. Stewart, BGP4: Inter-Domain Routing in the
Internet. Boston,MA, USA: Addison-Wesley Longman
Publishing Co., Inc., 1998.
[pfx-va] P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein,
"BGP Prefix Origin Validation", draft-ietf-sidr-pfx-
validate-01, working in progress.
9.2 Informative References
[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.
[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
Zhang Expires September 15, 2011 [Page 16]
INTERNET-DRAFT DBGP March 14, 2011
[BGPpop] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, "BGP Routing
Stability of Popular Destinations," in Proceedings of ACM
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.
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.
Zhang Expires September 15, 2011 [Page 17]
INTERNET-DRAFT DBGP March 14, 2011
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: mingui@huawei.com
Bin Liu
Tsinghua University
East Main Building RM9-416
Tsinghua University, Hai-Dian District,
Beijing, 100084 P.R. China
Email: lmyujie@gmail.com
Dacheng 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: zhangdacheng@huawei.com
Beichuan Zhang
University of Arizona
Computer Science Department,
The University of Arizona
Tucson, AZ 85721 U.S.A.
Email: bzhang@arizona.edu
Zhang Expires September 15, 2011 [Page 18]
Html markup produced by rfcmarkup 1.95, available from
http://tools.ietf.org/tools/rfcmarkup/