1868
IEEE/CAA JOURNAL OF AUTOMATICA SINICA, VOL. 8, NO. 12, DECEMBER 2021
DRRS-BC: Decentralized Routing Registration
System Based on Blockchain
Huimin Lu, Senior Member, IEEE, Yu Tang, and Yi Sun, Member, IEEE
   Abstract—The border gateway protocol (BGP) has become the
indispensible infrastructure of the Internet as a typical inter-
domain routing protocol. However, it is vulnerable to
misconfigurations and malicious attacks since BGP does not
provide enough authentication mechanism to the route
advertisement. As a result, it has brought about many security
incidents with huge economic losses. Exiting solutions to the
routing security problem such as S-BGP, So-BGP, Ps-BGP, and
RPKI, are based on the Public Key Infrastructure and face a high
security risk from the centralized structure. In this paper, we
propose the decentralized blockchain-based route registration
framework-decentralized route registration system based on
blockchain (DRRS-BC). In DRRS-BC, we produce a global
transaction ledge by the information of address prefixes and
autonomous system numbers between multiple organizations and
ASs, which is maintained by all blockchain nodes and further
used for authentication. By applying blockchain, DRRS-BC
perfectly solves the problems of identity authentication, behavior
authentication as well as the promotion and deployment problem
rather than depending on the authentication center. Moreover, it
resists to prefix and subprefix hijacking attacks and meets the
performance and security requirements of route registration.
    Index Terms—Blockchain, decentralized, routing protocol, routing
registration.
I.  Introduction
ITH the rapid development of network technology, how
W to effectively and securely manage the network is an
important issue. For scalability, the Internet is divided into
different autonomous systems (ASs). Each AS is consisted of
a group of hosts and routers under the administrative control
of an entity. It is a separate, manageable network group just
like a university, an organization, or a company. Correspond-
ingly, the routing protocols are also divided into two
categories, intra-domain routing protocol and inter-domain
Manuscript received June 17, 2020; revised August 18, 2020; accepted
September 3, 2020. This work was supported by the National Natural Science
Foundation of China (61601041) and the Fundamental Research Funds for the
Central Universities (2019PTB-003). Recommended by Associate Editor
Giancarlo Fortino. (Corresponding author: Yu Tang.)
Citation: H. M. Lu, Y. Tang, and Y. Sun, “ DRRS-BC: Decentralized
routing registration system based on blockchain,” IEEE/CAA J. Autom.
Sinica, vol. 8, no. 12, pp. 1868–1876, Dec. 2021.
H. M. Lu is with the College of Computer Science and Technology,
Qingdao University, Qingdao 266071, China, and also with the School of
Engineering, Kyushu Institute of Technology, Kitakyushu 804-8550, Japan
(e-mail: dr.huimin.lu@ieee.org).
Y. Tang and Y. Sun are with the School of Computer Science (National
Pilot Software Engineering School), Beijing University of Posts and
Telecommunications, Beijing 100876, China (e-mail: yutang@bupt.edu.cn;
sybupt@bupt.edu.cn).
Color versions of one or more of the figures in this paper are available
online at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/JAS.2021.1004204
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
routing protocol. The border gateway protocol (BGP) is a
typical inter-domain routing protocol which has become the
infrastructure of the Internet nowadays because of its robust
and reliable design of the routing function. However, the secu-
rity is weak and it even does not protect the authenticity to the
route advertisement. Therefore, it remains vulnerable to miscon-
figurations and malicious attacks, which would lead to instabi-
lity in the routing system or severe reachability problems.
The research by Murphy et al. [1], [2] shows that BGP has
significant design flaws and security risks in terms of security.
In BGP route propagation process, when a BGP router
performs route propagation, the AS can only advertise its own
prefix address block to the outside. The BGP neighbor node
accepts any routing update information sent by the peer by
default. In other word, the BGP router unconditionally trusts
the routing advertisement of the peer. Even if an AS
advertises a forged prefix while not its own, it will be
accepted by the peer and the protocol will continue to
propagate. This forged routing information will undoubtedly
lead to many security problems. The most typical is the prefix
hijacking which has caused many Internet security incidents.
In 2006 [3], AS174 illegally announced the address prefix
64.233.161.0/24 assigned to Google by AS15169, which
caused a large range of Google service requests to be
redirected to AS174 and eventually led to a large-scale
interruption of Google service requests. In 2006 [4], the
AS27506 incorrectly advertised the address prefix
166.84.0.0/16 and brought about a hijacking traffic to Panix
company. In 2008 [5], Pakistan Telecom (AS17557)
incorrectly announced YouTube’s prefix 208.65.153.0/24,
which caused the YouTube service to smash for 80 minutes
and caused Pakistan Telecom to be overwhelmed by a large
amount of network traffic. In 2017 [6], due to route
misconfiguration, Google Inc. accidentally hijacked the traffic
of NTT Communications Co., Ltd., causing a massive
network disconnection in Japan for about one hour.
NOCTION’s BGP Stream service has detected 3482 possible
BGP hijackings in the monitored network from November 28,
2015 to May 31, 2017, and there would be much more in the
global network.
Therefore, it is very important and necessary to solve the
BGP prefix hijacking problem and improve the security of
BGP. In this respect, the US BBN company proposed the
secure BGP protocol (S-BGP) in 2000 [7], [8]. S-BGP grants
the public key and certificate to the IP address prefix and the
AS owner to implement secure authentication of the address
LU et al.: DRRS-BC: DECENTRALIZED ROUTING REGISTRATION SYSTEM BASED ON BLOCKCHAIN
prefix and the AS identity. However, it brings about large
computational cost and prolonged path convergence time [9].
White proposed the secure origin BGP protocol (SoBGP) in
2003 [10]. The SoBGP authenticates the prefix and AS
identity by verifying the correctness and authorizing of the
data from BGP and can resist misconfiguration and prefix
hijacking. But the lack of the anchor’s address authorization
reduces the security of SoBGP and it cannot defend against
prefix-based hijacking attacks bases on routing policies [11].
And then, Orschot et al. proposed the pretty secure BGP
protocol (PsBGP) in 2007 [12]. The PsBGP uses the mutual
authentication between neighbors to prefix source AS
authentication. In the PsBGP, each AS creates a public key
certificate of its own BGP router and a prefix assertion list
PAL. Where PAL consists of a set of address prefixes owned
by itself and its neighbor ASs. However, due to the possibility
of “perjury” between ASs, the feasibility of this scheme is
greatly reduced. Hu proposed the security enhanced BGP
protocol (SE-BGP) in 2009 [13]. SE-BGP also uses certificate
system and its certificate structure adopts the DRCM
mechanism for AS Alliance. It introduces the TTM model to
realize the in-band transfer of trust relationships through two
signature conversions of key nodes. However, the protocol is
too complicated, not only too computationally expensive but
also difficult to deploy. Among these solutions, the most
feasible solution is RPKI which is an infrastructure based on
PKI led by the IETF’s SIDR working group. Its main purpose
is to provide authenticity verification for the correspondence
between IP prefix and AS number, and thus it effectively
prevents BGP prefix hijacking. However, the potentially
misconfigured, faulty or compromised RPKI authorities may
introduce new risk and the deployment of RPKI also makes
tardy progress. At present, there is only 6.55% address
coverage, and among the 6.55%, only 62.48% are effectively
protected [14]. Cooper et al. systematically analyzed the risk
of RPKI and pointed out that RPKI cannot prevent deleting
and overwriting of objects from malicious authorities [15].
Heilman et al. then proposed a mechanism to improve the
transparency of RPKI [16]. Birge-Lee et al. proposed
Bamboozling certificate authorities with BGP, but it still has
the problem of certificate overissuing [17]. Xing et al.
proposed BGPcoin system based on Ethereum which did not
design an independent blockchain system [18]. Although all
these solutions can protect the origin of IP address prefix, they
produce another serious risk that authentication rights may be
abused by authorities, which will damage the authenticity,
integrity and usability of resources. However, the idea that
utilizing blockchain to solve various problems is worth
learning in solving the security problem of BGP [19]–[21].
In order to both protect the origin of IP address prefix and
avoid centralized structural risk, in this paper, we innovatively
propose a decentralized route registration system based on
blockchain (DRRS-BC). In the proposed DRRS-BC, it records
and audits the Internet number resource allocation, validates
BGP origin route attestation and further authorizes and
distributes address prefixes and AS numbers between multiple
organizations and ASs. By applying blockchain, DRRS-BC
perfectly solves the problems of identity authentication and
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
1869
behavior authentication rather than depending on the
authentication center.
In a word, the contributions of this paper can be
summarized as follows.
1) We propose the decentralized blockchain-based route
registration framework in routing system to protect the origin
of IP address prefix and avoid centralized structural risk.
2) DRRS-BC establishes a global network resource
transaction ledge by the information of address prefixes and
AS numbers between multiple organizations and ASs, which
perfectly solves the security problems of identity
authentication and behavior authentication in traditional BGP
by introducing blockchain rather than depending on the
authentication center.
3) Security analysis shows that DRRS-BC is secure to
prefix and subprefix hijacking attacks. Experiments also show
that DRRS-BC system can meet the performance and security
requirements of route registration.
II.  DRRS-BC
In this section, we firstly give the overview of DRRS-BC
and then describe the proposed DRRS-BC in details.
A. Architecture Overview
Essentially speaking, DRRS-BC is a decentralized routing
information database constructed based on blockchain. This
database is jointly established by all organizations that
participate in the assignments and authorizations of address
prefixes and AS numbers and records every network resource
transaction between all organizations. It provides a tamper-
proof and traceable proof of ownership of the AS numbers and
address prefixes. The entire system consists of clients,
endorsement nodes, block generation nodes, and ledger
storage nodes without any authentication center. Each
organization runs a client, endorsement node, and several
ledger storage nodes. The core operators and organizations of
the Internet run block production nodes and each autonomous
system can also run a ledger storage node. The decentralized
architecture of DRRS-BC is depicted in Fig. 1.
When an organization needs to transfer an address prefix to
another organization, the organization’s client creates a
network resource transaction and broadcasts it to the
endorsement nodes of the organizations in the network
according to the endorsement strategy. After each
endorsement node receives the transaction request from the
client, it checks whether the transaction is qualified according
to the defined endorsement logic. If it is qualified, the
endorsement will be endorsed, and if it fails, it will reject the
endorsement. If the client receives enough endorsement
response, then the transaction endorsement succeeds, else the
endorsement fails and the client abandons the transaction.
After endorsement, it is the block producing phase. We apply
speculative Byzantine fault tolerance (SBFT) consensus
protocol between all block producing nodes to construct a
totally ordered sequence of endorsed transactions grouped in
blocks. Finally, the block producing node broadcasts the new
block and further transferred it to each ledger storage node
and then a network resource transaction ledger based on a
1870 IEEE/CAA JOURNAL OF AUTOMATICA SINICA, VOL. 8, NO. 12, DECEMBER 2021

Organization 5 Organization 4
Client Storage Storage
node Client
node

Endorsement
node Core organization of Endorsement
node
the Internet 1
Client Endorsement
node

Block Storage
production node
node

AS6
AS7
Storage Core organization of Core organization of
node Storage
the Internet 2 the Internet 3 node

Client Endorsement Client Endorsement

node node

Block Storage Block Storage

production node production node
node node

Organization 8
AS9
Client Storage
node
Storage
Endorsement node
node

Fig. 1. The architecture of DRRS-BC.

unified consensus between all organizations creates like this.
In the process of forming a global network resource
transaction ledge, each organization runs a variety of nodes.
Each type of node between organizations constitutes the entire
blockchain network and the system is permissioned. All nodes
that participate in the network have an identity provided by a
modular membership service provider. In other words, only
registered organizations can participate in this blockchain
system for network resource transactions.
There are four main types of nodes in the system.
Client is an entity that actually creates a transaction and it
can communicate with all endorsement nodes and block
production nodes in the network. When an organization wants
to initiate a network resource transaction, the client creates a
transaction according to a specific transaction structure. The
transaction structure will be described in detail in Section
II-B. Then, the client submits the transaction to each
endorsement node for endorsement. Finally, the client
constructs a legitimate transaction request and submits it to
each block production node.
Endorsement nodes are run in each organization. They
verify the transaction submitted by the client and complete the
The function is to arrange legitimate transactions into a well-
defined sequence, and package them into blocks for
subsequent distribution. These blocks will become the blocks
of the blockchain. The block production nodes collect all
legitimate transactions submitted by the client, verify their
endorsements, and package the transactions according to the
block size or time window. Finally, a globally unique block is
generated between the block production nodes through the
SBFT consensus protocol and broadcasted to each ledger
storage node.
Ledger storage nodes are run in each organization and
autonomous system. They are the ultimate storage nodes in
the network resource transaction blockchain. All BGP routers
or ASs in the network can access the ledger storage nodes and
query the ownership of the AS numbers and address prefixes.
The ledger storage nodes are responsible for periodically
receiving transaction blocks sorted by block production nodes,
conducting final checks on these transactions and maintaining
the blockchain ledger. Once the transactions are recorded in
the blockchain, the ledger can not be changed. They can
provide tamper proof and traceable proof of ownership of the
AS numbers and address prefixes.

endorsement of the transaction. After an endorsement node

receives the transaction endorsement request from the client, it
verifies the validity of the transaction according to the
verification rule. The validation rule will be described in detail
in Section II-B. If the transaction satisfies the validation rule,
the endorsement node attaches the endorsement signature of
the endorsement node to the transaction and sends the
message back to the client. Only when a transaction receives
enough endorsement signatures, the transaction will be
submitted as a legitimate transaction to the block production
nodes for consensus.
Block production nodes are run in the core operators and
organizations of the Internet and the number is determined.
B. DRRS-BC
DRRS-BC is also a system for authorizing and distributing
address prefixes and AS numbers between multiple
organizations and ASs. The transaction flow of DRRS-BC
across different types of nodes is depicted in Fig. 2.
There are three phases in the proposed DRRS-BC.
1) Phase 1: Construct Legitimate Transaction
The legitimate transaction construction phase involves an
interaction between a client and a set of endorsement nodes.
This phase is only concerned with the client asking different
organizations’ endorsement nodes to verify and agree the
client-created transactions.

Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
LU et al.: DRRS-BC: DECENTRALIZED ROUTING REGISTRATION SYSTEM BASED ON BLOCKCHAIN 1871

Create a (1) Verify (2) Collect (3) Submit legitimat (4) Block Form blockchain (5) Query the
transaction transaction endorsement transaction verification ledger blockchain
Create a transaction
Prefix address
authorization
10.0.0.0/8 (A→B)
Client A signature
(1) (1) (1) Block
...
ve production
Appro ve
(2) Collect Appro
TRANSACTION- e
s Sorting of
ENDORSED Refu
transactions;
(3)
Transaction
package;
Consensus
(4) algorithm (4)
(4) (4)
(4)
(4)
(5)

Client (C) Endorsement Endorsement Endorsement Block production Ledger Ledger Ledger
node 1 node 2 node 3 nodes storage storage storage
node 1 node 2 node 3

Fig. 2. The workflow of DRRS-BC.

To start this phase, the client creates a transaction proposal

according to the defined transaction structure, and then sends T1 P1 P1
P D1 D2
it to each of the required set of endorsement nodes for C1 S1
BP1 E1 E2
endorsement. The choice of endorsement nodes depends on L1 L1
the endorsement policy, which defines the set of organizations
T1 P T1 P D1
that need to endorse a proposed transaction before it can be T1 P D2 T1 P T1 P D1
T1 P T1 P D2
accepted by the network. Each endorsement node then
independently verifies the transaction proposal based on
defined validation rules and generate a transaction proposal
N
response indicating whether to endorse it. The endorsement
node endorses a proposal response by adding its digital Blockchain
C Client BP Block production
node
E Endorsement node
network
signature, and signing the entire payload using its private key. N
S
Ledger
storage node
P Endorsement policy L Blockchain ledger

This endorsement can be subsequently used to prove that this T Transaction P

organization’s endorsement node generated a particular
response. When the client receives signed proposal responses
from sufficient endorsement nodes, it attaches the endorse-
ment policy and the digital signature of every collected
endorsement node behind this transaction. So, a legitimate
transaction consists of a transaction proposal, an endorsement
policy and the digital signature of endorsement nodes.
For ease of understanding, we use the following example to
explain Phase 1 in detail in Fig. 3.
In this example, the client C1 generates the transaction
proposal T1 and the set of endorsement nodes P which defines
E1 and E2 as endorsement nodes. When the endorsement node
E1 receives T1 and P, it verifies the transaction proposal T1
according to the endorsement policy P1 and synchronized
ledger L1 at this moment. If the transaction passes verifica-
tion, the endorsement node E1 generates the digital signature
D1 as a response. Independently, the endorsement node E2
also generates a response D2 in the same way. Finally, after
the client C1 collects sufficient response, it constructs a
legitimate transaction and submits it to block production
nodes.
● Transaction structure
Transactions are the most important part in DRSS-BC.
Everything else in DRRS-BC is designed to ensure that
The set of
endorsement nodes
D
The signature of
endorsement node
Fig. 3. The schematic of Phase 1.
transactions can be created, propagated, validated, and finally
added to the global ledger of the blockchain. In this system, a
transaction consists of transaction header, input and output.
The specific structure shown in Fig. 4 is as follows.
a) Transaction header contains four parameters (Txid,
Timestamps, Rental_Period, and Type)
Txid: An identifier used to uniquely identify a particular
transaction. Specifically, the SHA256 hash of the transaction.
Each transaction can be found via Txid.
Timestamps: The Unix time that the client creates the
transaction. If this transaction is recorded in the blockchain,
the use time of this address prefix will start from this
timestamp.
Rental_Period: The time interval an address prefix is
authorized. If Rental_Period is zero, it means that an
organization authorizes or assigns a prefix address to another
organization or autonomous system. If Rental_Period is non-
zero, it means that an organization leases a prefix address to
another organization or autonomous system.
Type: The type of a transaction. If Type is zero, it means
that the transaction was authorized by one organization to

Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
1872
delegate one address prefix to another organization. If Type is
non-zero, it means that an organization assigns an address
prefix to one of its autonomous systems and the value of Type
is AS number.
Each transaction contains one input and multiple outputs.
Each transaction input must come from the previous
transaction output and each output waits as an unspent
transaction output until a later input spends it. So, all
transactions are chained together.
b) The input of the transaction is composed of (PreTxid,
Index, <sigA>, and <PubkA>)
PreTxid: The Txid of a previous transaction.
Index: The output number of the previous transaction.
<sigA>: The client who created the transaction digitally
signs the transaction with his own private key. S K A is the
private key of client A.
<PubkA>: The public key of client A. Each organization has
a unique pair of public and private keys, the public key can be
public, and the private key is kept as a secret.
The digital signature process is as follows, where sign(·) is a
signature function:
⟨sigA ⟩ = sign skA (PreT xid, Index).
c) The output of the transaction may be one, two, or three
If an address prefix is completely transferred to another
organization, the output is only one. If an address prefix only
transfers the first half or the second half to another
organization, the output is two. If an address prefix only
transfers the middle part to another organization, the output is
three. For example, an organization A owns the address prefix
[a, b]. There are three ways to transfer this address prefix.
Case 1: If organization A transfers the address prefix [a, b]
to organization B, the output is {1, [a, b], 0, <PubkB>}.
Case 2: If organization A transfers the address prefix [a, c]
to organization B , where a>c>b. The output is {1, [a, c], 0,
<PubkB>},{2, [c, b], 0, <PubkA>}.
Case 3: If organization A transfers the address prefix [d, e]
to organization B, where a<d<e<b. The output is {1, [a, d], 0,
<PubkA>}, {2, [d, e], 0, <PubkB>}, {3, [e, b], 0, <PubkA>}.
The transactions recorded in the blockchain indicate that an
address prefix has been transferred to another organization or
an autonomous system. During the transmission process of
address prefix, the global ledger needs to be jointly
maintained by the whole nodes and keeps consistent. In other
words, each address prefix belongs to a unique organization or
autonomous system. Therefore, the proposed input and output
transaction structure makes each transaction traceable. Each
output of a particular transaction can only be used as an input
once in the blockchain. If the value of a transaction’s output
exceeds its input, the transaction will be rejected. Fig. 5 shows
the relationship between transactions.
2) Phase 2: Produce Block
The block production phase is to package legitimate
transactions submitted from clients and generate a globally
unique block between all block producing nodes through
consensus algorithm. The blockchain producing nodes are
pivotal to this process. They order each transaction according
to the packaging rules and package batches of transactions
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
IEEE/CAA JOURNAL OF AUTOMATICA SINICA, VOL. 8, NO. 12, DECEMBER 2021
Txid: xxx...xxxx
Timestamps: xxxxxx
Rental_Period: xxxxx
Type: xxx
Input Output
Index 1,
PreTxid: xxx...xxx address, AS, <Pubk 2>
Index: xxx ...
<sig><Pubk 1> Index N,
Address, AS, <Pubk N>
Fig. 4. The structure of a transaction.
into blocks. Finally, they generate a unique block through the
consensus algorithm and distribute back to all ledger storing
nodes and endorsing nodes.
To start this phase, the block production nodes receives
proposed legitimate transactions from many clients in the
network. They check the endorsement of each transaction
received, arrange these effective transactions into a well-
defined sequence and package them into blocks for
subsequent distribution. Once a block producing node has
generated a block of the desired size, or after a maximum
elapsed time, it will initiate a consensus process to generate a
unique block for the current period and the block will be sent
to all ledger storing nodes and endorsing nodes. These blocks
will become the blocks of the blockchain.
We also use the example to explain this phase in detail in
Fig. 6.
In this example, the client C1 sends a transaction T1
endorsed by endorsement node E1 and E2 to the block
production nodes. In parallel, the client C2 and C3 separately
send the transaction T2 and T3 to the block production nodes.
The block production nodes verify and sort the received
transactions and package them into block. A globally unique
block B is created by consensus algorithms between nodes.
Finally, the transaction order of T1, T2, T3, etc., is recorded in
the blockchain.
3) Phase 3: Verify Block
The block verification phase of the transaction workflow is
to check block format and add the verified block to the
blockchain. When a new block is generated, all of the peers
connected to the block producing nodes will be sent a copy of
the new block. Each peer checks the new block independently,
but in exactly the same way so that the ledger can be kept
consistent.
● Validation rules
When the transaction proposal is sent to the endorsement
nodes according to the endorsement policy, each endorsement
node then independently verifies the transaction proposal
based on defined validation rules and generate a transaction
proposal response indicating whether to endorse it. The design
of validation rules needs to meet the definition of address
prefix resource delegation and assignment.
Definition 1: An organization transfers its address prefix
resources to other organizations and the receivers has the right
to further delegate the address prefix.
Definition 2: An organization assigns its address prefix
resources to its own AS or AS for its service, but the AS can
LU et al.: DRRS-BC: DECENTRALIZED ROUTING REGISTRATION SYSTEM BASED ON BLOCKCHAIN 1873

D leases [1000000000,
1020000000] to F for 1 year.

{uy38… 99xs, 1473027325000,

31536000, 0}

Input Output
{1,
[1000000000,
1020000000], 0,
C authorizes [1000000000, {tr34…t4u5, 1, <PubkF>}
1050000000] to D <sigD>,
{2,
<PubkD>}
[1020000000,
1050000000], 0,
{tr34…t4u5, 1430864125000,
<PubkD>}
0,0}

Input Output
{1,
[1000000000, {jkg2…54gb, 1480889725000,
1050000000], 0, 0, 0}
{ersf…de2j, 1, <PubkD>}
<sigC>,
{aasd…dw2d, 1396736125000, {2, Input Output
{ersf…de2j, 1399328125000, <PubkC>}
0,0} [1050000000, {1,
0, 0}
1100000000], 0, [1050000000,
Input Output <PubkC>} 1070000000], 0,
Input Output
{1, <PubkC>}
[1000000000, {2,
1100000000], 0, [1070000000,
{1, {aasd…dw2d, {yhgd…45sh, 1459894525000, {tr34…t4u5, 2,
{sse2…de34, 1, <PubkC>} 1090000000],
[1000000000, 1, 0,12354} <sigC>,
<sigA>, 11323,
1200000000], 0, <sigB>, {2, <PubkC>}
<PubkA>} <PubkG>}
<PubkB>} <PubkB>} [1100000000,
1200000000], 0, Input Output
{3,
<PubkB>}
[1090000000,
1100000000], 0,
A authorizes [1000000000, B authorizes [1000000000, {1, <PubkC>}
1200000000] to B 1100000000] to C {ersf…de2j, 2, [1100000000,
<sigB>, 1200000000], C allocates [1070000000,
<PubkB>} 12354, 1090000000] to AS11323
<PubkE>}

B allocates [1100000000,
1200000000] to AS12354

Fig. 5. The relationship between transactions.

no longer delegate these address prefixes.

Consensus Definition 3: An address prefix cannot be simultaneously
Header
T1 P1 D1 D2 BP4 BP3 L1 T1
T2
transferred to two organizations or ASs.
T3
C1 T... B Definition 4: If an organization does not own this address
prefix, the address prefix cannot be transferred to another
T2 P2 D1 D3 D5 E1 S1
BP1 BP2 organization.
C2
Definition 5: If an organization leases an address prefix to
T3 P3 D2 D3 D4 Header another organization, the transaction automatically expires
C3 T1 P1 D1 D2
T2 P2 D1 D3 5
T1
T2
T3
beyond the lease period.
T3 P3 D2 D3D4 T... B
T... P... D... ● Packaging rules
T… P... D...

C... The blockchain production nodes order each transaction and

N
package batches of transactions into blocks. They encapsulate
C Client BP Block production E Endorsement node
the transaction data received over a period of time into a time-
Blockchain node
network stamped block and connect it to the current longest main
N
S
Ledger
storage node
Header
Block L Blockchain
ledger
B blockchain using the linked list structure. Each block of the
The set of The signature of
T Transaction P
endorsement nodes
D
endorsement node DRRS consists of a block header and a block body. The block
header contains the version number, the Hash value of the
Fig. 6. The schematic of Phase 2. previous block, the current block height, the Merkle root of

Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
 1874
the current transactions, the timestamp, and the block
signature. The block body packs the verified and sorted
transactions in the current time period.
  
III.  Security Analysis
In this section, we analyze the security of DRRS-BC in the
light of the threat model. The target of the adversaries in our
model is prefix or subprefix hijacking. That means a network
operator that has not been authorized to originate a prefix
announces in the BGP route massage that the prefix is bound
to its own AS number (ASN), and this false route origination
is legitimized successfully and accepted by the BGP system.
Hackers can achieve prefix hijacking by forging network layer
reachability information in BGP update. In the following, we
show how DRRS-BC defends against these attacks.
Prefix Hijacking: Prefix hijacking means that an AS
advertises an unauthorized prefix. The so-called “unauthori-
zed” means that the prefix belongs to other ASs or the address
space of this segment has not been allocated. The allocation of
Internet addresses follows the authorization level from IANA
to regional Internet registries (RIR) to local Internet registries
(LIR). If the AS violates the authorization to announce illegal
prefixes, it will directly cause traffic hijacking. In this case,
the malicious AS forges the NLRI information in the BGP
Update message and advertises an illegal prefix. As shown in
Fig. 7(a), AS1 is the legal owner of the prefix 16.1.0.0/16, and
it advertises the route to this segment of the URL. As shown
in Fig. 7(b), AS5 maliciously forged NLRI and also advertised
the route to 16.1.0.0/16. In this way, according to the principle
of BGP selecting the shortest AS_PATH path, AS4 will
preferentially select the path from AS5 to 16.1.0.0/16.
NLRI: 16.1.0.0/16 AS3
NLRI: 16.1.0.0/16
AS_PATH: 2, 1 AS_PATH: 3, 2, 1
NLRI: 16.1.0.0/16 AS2 AS4
AS_PATH: 1
AS1 AS5
(a) AS1 advertises legal 16.1.0.0/16
NLRI: 16.1.0.0/16 AS3 NLRI: 16.1.0.0/16
AS_PATH: 2, 1 AS_PATH: 3, 2, 1
NLRI: 16.1.0.0/16 AS2 AS4 NLRI: 16.1.0.0/16
AS_PATH: 1 AS_PATH: 5
AS1 AS5
(b) AS5 announces forged 16.1.0.0/16
Fig. 7. Prefix hijacking.
In a prefix hijacking attack, the adversarial AS5 announces
identical BGP prefix that belongs to the victim AS1. Since
AS4 has joined DRRS-BC and its local blockchain ledger has
been synchronized, 16.1.0.0/16 legally declared by AS1 has
been recorded in the ledger. In the taxonomy of blockchains,
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
IEEE/CAA JOURNAL OF AUTOMATICA SINICA, VOL. 8, NO. 12, DECEMBER 2021
this attack can be considered as double-spending. Therefore,
the prefix update information forged by AS5 will be easily
identified by DRRS-BC, and AS4 will reject the routing
update information sent by AS5.
Subprefix Hijacking: The subprefix hijacking occurs when
an attacker announces de-aggregated thus a more specific IP
prefix than the actual owner of the prefix. The longest prefix
match rule prefers more specific route. In this attack, A
announces more specific prefixes than the ones owned by A.
As such, this behavior cannot be immediately detected as a
double-spent transaction since routing table will not have a
prior transaction linked to V that contains prefixes announced
by A. In this case, AS1 is the legal owner of the prefix
16.1.0.0/16, and it advertises the route to the segment of the
URL. In Fig. 8 , AS5 maliciously forged NLRI and also
advertised the route to 16.1.0.0/20. In this way, according to
the longest matching principle of BGP, all other ASs will
choose the fake path.
NLRI: 16.1.0.0/20 AS3 NLRI: 16.1.0.0/20
AS_PATH: 3, 4, 5 AS_PATH: 4, 5
NLRI: 16.1.0.0/16 AS2 AS4 NLRI: 16.1.0.0/20
AS_PATH: 1 AS_PATH: 5
AS1 AS5
Fig. 8. Forged sub-prefixes in NLRI information.
In a subprefix hijacking attack, the adversarial AS5
announces a subset of the BGP prefixes belonging to the
victim AS1. The transaction structure of DRRS-BC makes the
output of each transaction come from the input of the previous
transaction, and the attribution of any sub-prefix can be traced
back to its prefix set. Therefore, the proposed input and output
transaction structure makes each transaction traceable. Each
output of a particular transaction can only be used as an input
once in the blockchain. Since AS2, AS3, AS4 all have joined
DRRS-BC and their local blockchain ledgers have been
synchronized, the prefix update information forged by AS5
will be easily identified by DRRS-BC, and all AS will reject
the routing update information sent by AS5.
Because the global network resource allocation is recorded
in the blockchain, and all synchronized ledgers maintain the
consistency of transactions, all inter-domain routers and any
audit program can access it and verify the authenticity of
routing information. Therefore, based on historical trustworthi-
ness, autonomous transaction auditing, and explicit resource
ownership, DRRS-BC can minimize the ability of authorized
institutions to eliminate the risk of configuration errors.
IV.  Simulation and Results
The purpose of our system is to store the IP prefix addresses
registered by all autonomous systems and to ensure the
consistency of ownership of all IP prefix addresses. So we
could evaluate DRRS-BC system’s suitability and perform-
ance in a real-life scenario. To this end, we deployed the
above system in the Alibaba Cloud service and analyzed some
performance indicators. We separately evaluated the
LU et al.: DRRS-BC: DECENTRALIZED ROUTING REGISTRATION SYSTEM BASED ON BLOCKCHAIN 1875

transaction performance of the system, the scalability of the In order to test the impact of block size on the processing
system, and the impact of block size on the processing efficiency of the system, we fill blocks of different sizes with
efficiency of the system. real transactions. Before the block consensus, each production
For system performance evaluation, we tested the system’s node will perform various verifications on the transactions in
processing time for different quantities of transactions by the block, so the size of the block will directly affect the
sending a large number of transactions to the system. Since overall operating efficiency of the system. The more
the construction of each transaction needs to undergo transactions that are included in the block in Table II , the
verification of UTXO status, transaction construction, greater the processing delay of the block.
transaction signature, sending transaction, etc. The throughput
of the system is closely related to the processing efficiency of TABLE II
the transaction. The experimental results (Fig. 9) show that System Operation Efficiency Test Result
each autonomous system can send 39 transactions per second Block size Number of transaction Block processing time
to the network in the DRRS-BC system. This performance is 1M 4594 txs 9.06 s
sufficient for the performance requirements of organizations
2M 9256 txs 17.58 s
and autonomous systems for IP prefix registration.
3M 13821 txs 25.97 s
180 4M 18542 txs 37.48 s
160 157.05
140 5M 23102 txs 45.73 s
Cost of time (s)

120 129.915
100 96.48
80 72.3 82.46 In summary, in order to make the DRRS-BC system meet
59.62
60 60.45
40 26.82
the performance requirements of route registration, we
36.48
20 2.325 actually set up 16 production nodes and 1 M block size system
12.155
0 for deployment. The DRRS-BC is incrementally deployable
100 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Number of transactions and backwards compatible with the current operations of ASs.
Organizations and autonomous systems can use the DRRS-BC
Fig. 9. Transaction processing efficiency.
as an additional security feature in parallel with existing
For the evaluation of system scalability, we tested the routing policies and do not require the AS to switch from the
impact of different numbers of nodes and block sizes on the old system to the new protocol paradigm.
  

formation of the final consensus block. In Table I, the increase

in the number of nodes leads to a time-consuming increase in
the process of final consensus, and the larger the block, the
more time-consuming process of the final consensus process.
When the number of nodes increases, the communication
complexity required for consensus increases. The block size
affects the increase in the amount of communication data, so
when the network bandwidth is constant, the block size will
affect the delay of the consensus process.
TABLE I
System Scalability Test Results
Number of production nodes
4 nodes
4 nodes
4 nodes
6 nodes
6 nodes
V.  Implementation and Deployment
The prototype system consists of a set of clients,
endorsement nodes, block production nodes and blockchain
ledger that perform all typical operations for the Internet
resource and a client written in Go to interact with the
blockchain nodes deployed in the P2P network.
We collected some real resource delegations (IP addresses
and ASNs) from IANA to RIR, RIR to NIR, NIR to ISP and
encoded them into the genesis block, and reproduced the IP
address prefix and Internet number assignment and
registration process in our experiment. Each organization and
Block size (k) Latency autonomous system deploys the client and generates the
1024 339 ms address and corresponding private key of each entity. Each
2048 412 ms entity can register, lease, assign, and revoke related Internet
4096 673 ms resources through the client. And we map the resource
1024 487 ms delegations in the real world to four kinds of transactions,
IPregister, IPlease, IPassign, IPrevoke, that the resource
2048 568 ms
delegator sent to the delegate.

6 nodes 4096 953 ms

8 nodes 1024 512 ms VI.  Conclusions
8 nodes 2048 656 ms In this work, we proposed the decentralized blockchain-
8 nodes 4096 1.13 sec based route registration framework-DRRS-BC, which can
16 nodes 1024 567 ms resist to prefix or subprefix hijacking attacks. By applying
16 nodes 2048 872 ms blockchain, DRRS-BC perfectly solves the problems of
16 nodes 4096 1.58 sec identity authentication, behavior authentication as well as the
promotion and deployment problem rather than depending on
the authentication center. Our future work will study how to

Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
1876 IEEE/CAA JOURNAL OF AUTOMATICA SINICA, VOL. 8, NO. 12, DECEMBER 2021
combine blockchain with other technologies such as Internet
of Things [22], cloud computing, edge computing [23], and
sensor network [24] to design a new BGP protocol that is
suitable for practical applications.
References
[1] S. Murphy, BGP Security Vulnerabilities Analysis, RFC 4272, 2006.
[2] O. Nordström and C. Dovrolis, “ Beware of BGP attacks,” ACM
SIGCOMM Comput. Commun. Rev., vol. 34, no. 2, pp. 1–8, Apr. 2004.
[3] T. Wan and P. C. van Oorschot, “Analysis of BGP prefix origins during
Google’s May 2005 outage,” in Proc. 20th IEEE Int. Parallel &
Distributed Processing Symp., Rhodes, Greece, 2006.
[4] R. Blog, “ Con-Ed steals the net,” [Online]. Available:
http://www.renesys.com/blog/2006/01/coned_steals_the_net.shtml.
Accessed on: 2006.
[5] R. Blog, “ Pakistan hijacks YouTube,” [Online]. Available:
http://www.renesys.Com/blog/2008/02/pakistan_hijiacks_youtube_1.sht
ml. Accessed on: 2008.
[6] Sohu News, “ Google accidentally hijacked BGP routes,” [Online].
Available: http://www.sohu.com/a/168006154_257305 . Accessed on:
Aug. 29, 2017.
[7] S. Kent, C. Lynn, and K. Seo, “ Secure border gateway protocol (S-
BGP),” IEEE J. Sel. Areas Commun. , vol. 18, no. 4, pp. 582–592, Apr.
2000.
[8] S. T. Kent, “Securing the border gateway protocol: A status update,” in
Proc. 7th IFIP TC-6 TC-11 Int. Conf. Communications and Multimedia
Security, Torino, Italy, 2003.
[9] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, “ Secure border gateway
protocol (S-BGP)—Real world performance and deployment issues,” in
Proc. Network and Distributed System Security Symp., San Diego, USA,
2000.
[10] R. White, “ Securing BGP through secure origin BGP (soBGP),” Bus.
Commun. Rev., vol. 33, no. 5, pp. 47–53, 2003.
[11] G. Huston, M. Rossi, and G. Armitage, “ Securing BGP—A literature
survey,” IEEE Commun. Surv. Tut. , vol. 13, no. 2, pp. 199–222, Jan.
2011.
[12] P. C. van Oorschot, T. Wan, and E. Kranakis, “On interdomain routing
security and pretty secure BGP (psBNGP),” ACM Trans. Inf. Syst.
Secur., vol. 10, no. 3, p. 11, Jul. 2007.
[13] X. J. Hu, “ Research on inter-domain routing system security,” Ph.D.
dissertation, National Univ. Defense Technology, Changsha, China,
2009.
[14] Y. Gilad, A. Cohen, A. Herzberg, M. Schapira, and H. Shulman, “Are
we there yet? On RPKI’s deployment and security,” in Proc. NDSS
Symp., San Diego, USA, 2017.
[15] D. Cooper, E. Heilman, K. Brogle, L. Reyzin, and S. Goldberg, “On the
risk of misbehaving RPKI authorities,” in Proc. 12th ACM Workshop on
Hot Topics in Networks, College Park, USA, 2013, pp. 16.
[16] E. Heilman, D. Cooper, L. Reyzin, and S. Goldberg, “From the consent
of the routed: Improving the transparency of the RPKI,” ACM
SIGCOMM Comput. Commun. Rev., vol. 44, no. 4, pp. 51–62, Oct. 2014.
[17] H. Birge-Lee, Y. X. Sun, A. Edmundson, J. Rexford, and P. Mittal,
“Bamboozling certificate authorities with BGP,” in Proc. 27th USENIX
Security Symp., Baltimore, USA, 2018, pp. 833–849.
[18] Q. Q. Xing, B. S. Wang, and X. F. Wang, “BGPcoin: Blockchain-based
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:18:56 UTC from IEEE Xplore. Restrictions apply.
internet number resource authority and BGP security solution,”
Symmetry, vol. 10, no. 9, p. 408, Sept. 2018.
[19] A. Buzachis, A. Celesti, A. Galletta, M. Fazio, G. Fortino, and M.
Villari, “ A multi-agent autonomous intersection management (MA-
AIM) system for smart cities leveraging edge-of-things and
blockchain,” Inf. Sci., vol. 522, pp. 148–163, Jun. 2020.
[20] G. Fortino, F. Messina, D. Rosaci, and G. M. L. Sarné, “Using
blockchain in a reputation-based model for grouping agents in the
internet of things,” IEEE Trans. Eng. Manage. , vol. 67, no. 4,
pp. 1231–1243, Nov. 2020.
[21] G. Fortino, F. Messina, D. Rosaci, and G. M. L. Sarne, “ResIoT: An IoT
social framework resilient to malicious activities,” IEEE/CAA J. Autom.
Sinica, vol. 7, no. 5, pp. 1263–1278, Sept. 2020.
[22] R. Casadei, G. Fortino, D. Pianini, W. Russo, C. Savaglio, and M.
Viroli, “ Modelling and simulation of opportunistic IoT services with
aggregate computing,” Future Generat. Comput. Syst. , vol. 91,
pp. 252–262, Feb. 2019.
[23] G. R. Alam, M. M. Hassan, Z. Uddin, A. Almogren, and G. Fortino,
“Autonomic computation offloading in mobile edge for IoT
applications,” Future Generat. Comput. Syst., vol. 90, pp. 149–157, Jan.
2019.
[24] G. Fortino, D. Parisi, V. Pirrone, and G. Di Fatta, “BodyCloud: A SaaS
approach for community body sensor networks,” Future Generat.
Comput. Syst., vol. 35, pp. 62–79, Jun. 2014.
Huimin Lu (SM’ 19) received the B.S. degree in
electronics information science and technology from
Yangzhou University in 2008. He received the M.S.
degrees in electrical engineering from Kyushu
Institute of Technology and Yangzhou University in
2011. He received the Ph.D. degree in electrical
engineering from Kyushu Institute of Technology in
2014. From 2013 to 2016, he was a JSPS Research
Fellow at Kyushu Institute of Technology. Currently,
he is an Associate Professor in Kyushu Institute of
Technology and an Excellent Young Researcher of MEXT-Japan. His
research interests include computer vision, robotics, artificial intelligence, and
ocean observing.
Yu Tang is a Ph.D. candidate of Beijing University
of Posts and Telecommunications. He received the
B.S. degree in electronic information science and
technology from Xidian University in 2016. His
research interests include blockchain, distributed
system, and network security.
Yi Sun (M’20) received the Ph.D. degree from State
Key Laboratory of Networking and Switching Techno-
logy, Beijing University of Posts and Telecommu-
nications in 2015. Currently, she is a Lecturer of
Beijing University of Posts and Telecommunications.
Her research interests include information security,
privacy-preserving data mining, secure multiparty
computation, malware detection and blockchain.