[PPT] - A Blockchain-based Mapping System IETF 98 Chicago March 2017 PowerPoint Presentation

SLIDE 1

A Blockchain-based Mapping System

IETF 98 – Chicago March 2017

Jordi Paillissé, Albert Cabellos, Vina Ermagan, Fabio Maino

acabello@ac.upc.edu

htup://openoverlayrouter.org

1

SLIDE 2

A short Blockchain tutorial

2

SLIDE 3

Blockchain - Introductjon

Blockchain = decentralized, secure and

trustless database

Add blocks of data one afuer another
Protected by two mechanisms:

– Chain of signatures – Consensus algorithm

First appeared: Bitcoin, to exchange money
Many more applicatjons are possible

3

SLIDE 4

Blockchain - Transactjons

4

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

SLIDE 5

Blockchain - Transactjons

5

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

Transactjons are broadcasted to all the nodes

P2P network

1

SLIDE 6

Blockchain - Transactjons

6

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

Prev. Hash

Nonce Transactjons 1 ··· N

Block Transactjons are broadcasted to all the nodes

2

A node collects transactjons into a block

P2P network

1

SLIDE 7

Blockchain - Transactjons

7

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

Prev. Hash

Nonce Transactjons 1 ··· N

Block

Prev. Hash

Nonce Transactjons 1 ··· N’

New Block Transactjons are broadcasted to all the nodes

2

A node collects transactjons into a block

3

Compute consensus algorithm

P2P network

1

SLIDE 8

Blockchain - Transactjons

8

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

Prev. Hash

Nonce Transactjons 1 ··· N

Block

Prev. Hash

Nonce Transactjons 1 ··· N’

New Block Transactjons are broadcasted to all the nodes

2

A node collects transactjons into a block

P2P network

1 4

Broadcast new block to the network

3

Compute consensus algorithm

SLIDE 9

Blockchain - Transactjons

9

Sender’s Public Key Sender’s signature

Transactjon

Tx Data

Prev. Hash

Nonce Transactjons 1 ··· N

Block

Prev. Hash

Nonce Transactjons 1 ··· N’

New Block Transactjons are broadcasted to all the nodes

2

A node collects transactjons into a block

5

The other nodes verify the consensus algorithm and accept the block

P2P network

1 4

Broadcast new block to the network

3

Compute consensus algorithm

SLIDE 10

Blockchain - Propertjes

Decentralized: all nodes have the entjre

blockchain

No prior trust required
Decouples ownership from identjty
Append-only and immutable: added

transactjons cannot be modifjed

Verifjable

10

“Blockchain Technology”, Sutardja Center (UC Berkeley) htup://scet.berkeley.edu/wp-content/uploads/BlockchainPaper.pdf

SLIDE 11

A Blockchain-based Mapping System Overview

11

SLIDE 12

Basic Idea

Objectjve: Securely store:

– EID prefjx delegatjons (as in RPKI or DDT-ROOT) – EID-to-MS informatjon (as in DDT) – EID-to-RLOC mappings (as in MS)

Map Resolvers read the blockchain to fjnd the

mappings

Idea: An EID is equivalent to a coin

– Wallet: A set of EIDs – Transactjon: Delegatjng EIDs or binding them to a MS or a set

f RLOCs

– Blockchain: A public ledger of the transactjons

12

SLIDE 13

A Blockchain-based Mapping System Storing EID delegatjons and EID-to-RLOC mappings

13

SLIDE 14

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

14

WRITE

SLIDE 15

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

15

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping Delegatjon WRITE

SLIDE 16

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

16

EID-prefjx

wner

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping 3-Writes Prefjx  EID-to- RLOC mapping Delegatjon Delegatjon WRITE

SLIDE 17

1 2 ... n n+1 n+2 blockchain ROOT ROOT 2-Fetch mappings 1-Writes Genesis block, claims all EID space 1-Map-Request 3-Map-Reply EIDpref  RLOC1  RLOC2  RLOC3 WRITE READ

17

EID-prefjx

wner

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping Delegatjon Delegatjon

xTR MR/MS with blockchain

3-Writes Prefjx  EID-to- RLOC mapping

SLIDE 18

A Blockchain-based Mapping System Storing EID delegatjons and EID-to-MS informatjon

18

SLIDE 19

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

19

WRITE

SLIDE 20

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

20

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping Delegatjon WRITE

SLIDE 21

1 2 ... n n+1 n+2 blockchain ROOT ROOT 1-Writes Genesis block, claims all EID space

21

EID-prefjx

wner

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping 3-Writes Prefjx  EID-to- MS informatjon Delegatjon Delegatjon WRITE

SLIDE 22

1 2 ... n n+1 n+2 blockchain ROOT ROOT 2-Fetch EID-to-MS informatjon 1-Writes Genesis block, claims all EID space 1-Map-Request 3-Map-Reply WRITE READ

22

EID-prefjx

wner

EID-prefjx

wner

EID-prefjx

wner

2-Writes Prefjx  owner mapping Delegatjon Delegatjon

xTR MR

3-Writes Prefjx  EID-to- MS informatjon 2-Map-Request

MS (in proxy-mode, as an example)

SLIDE 23

Pros and Cons

Pros

Infrastructure-less and

decentralized

Fast lookup
Secure, without certs

– Non-repudiatjon – Resilience – Integrity – Authentjcatjon

No prior trust required
Simple rekeying

Cons

Challenges with incentjves
Slow updates

– Mappings can be stored in a MS, then performance is as fast as DDT

Costly bootstrapping
Large storage required

23

Can be mitjgated using a dedicated chain

SLIDE 24

Comparison with LISP-DDT

LISP-DDT Blockchain

+ Less infrastructure + No certjfjcates + Fast queries

Large storage required
Update mappings slow  Store Mappings

in MS (same performance as MS)

24

Root Root DDT1 DDT1 MS1.1 MS1.1 MS1.2 MS1.2 DDT2 DDT2 MS2.1 MS2.1

Node 1

Chain Chain

Node 2

Chain Chain

Node N

Chain Chain

…

+ Fast update  Dynamic mappings

Manual confjguratjon

SLIDE 25

Issues with RPKI

RPKI Blockchain Anonymity [1] Prefjxes linked to owner name Prefjxes linked to a public key Revocatjon Performed by CAs Performed automatjcally (validity tjme) or impossible Certjfjcate management [2] Complex No certjfjcates

25

[1] Wählisch, Matuhias, et al. "RiPKI: The tragic story of RPKI deployment in the Web ecosystem." Proceedings of the 14th ACM Workshop on Hot Topics in Networks. ACM, 2015. [2] George, Wes. "Adventures in RPKI (non) Deployment." NANOG, 2014.

SLIDE 26

Scalability

26

One mapping for each block of /24 IPv4 address space
Growth similar to BGP churn*
Prefjx delegatjon + mappings
Each transactjon approx. 400 bytes
Only prefjxes: approx. 40 GB in 20 years (worst case + BGP table growth*)

*Source: htup://www.potaroo.net/ispcol/2017-01/bgp2016.html

Approx. 600 GB in 2034

SLIDE 27

A Blockchain-based Mapping System Transactions

27

SLIDE 28

First transaction

Map-Resolver trust the Public Key of the Root,

that initially claims all EID space by writing the genesis block

Root can delegate all EID space to itself and use

a different keypair

“I own all the address space” Hash(P+ root)= Root@1 Root@2 New Transaction

28

SLIDE 29

Prefix delegation

Root delegates EID-prefixes to other entities

(identified by Hash(Public Key)) by adding transactions

“delegate” Root@2 Root@3 (rest of space) New Transaction 0.0/16 Deleg1@ 25.5.5/8 Deleg2@

Owners can further delegate address blocks to other

entities or write MS addresses (and MS’s Public Key)

“delegate” Deleg1@ Deleg1@2 (rest of space) New Transaction 0.0.1/24 Deleg3@ 0.0.2/24 MS@ and P+

29

SLIDE 30

Writing mappings

Just like delegating a prefix, but instead of the

Map Server address, we write the mapping

“mapping” Deleg3@ New Transaction 0.0.1/24 is at RLOC1

30

SLIDE 31

Rekeying

Delegating the owned EID-prefixes to itself using

a new key set.

Simpler than traditional rekeying schemes
Can be performed independently, i.e. each
wner can do it without affecting other owners
Same procedure for mappings

31

SLIDE 32

Map-Reply Authentication

MS public key can also be included in the

delegations

Since blockchain provides authentication and

integrity for this key, MRs can use it to verify Map-Replies

2-Retrieve MS RLOC and MS’s Public Key 3-Map-Request 4-Signed Map-Reply With MS’s Private Key 6-Map-Reply 5-Verify signature 1-Map-Request

32

xTR MR MS

SLIDE 33

A Blockchain-based Mapping System Prototyping

33

SLIDE 34

Design consideratjons

Bitcoin is too restrictjve:

– Only for money transfer – Huge blockchain fjle size (approx. 100 GB) – High bootstrap tjme (several days*) – Low throughput (7 transactjons/sec.)

New blockchain technologies:

– More scalable – Smart contracts

34

*depends on connectjon speed

SLIDE 35

Dedicated chain

Public (anyone can use it) but dedicated (only

for mappings)

Stores:

– Prefjx delegatjons – Replaces DDT ROOT – EID-to-MS informatjon – Replaces DDT-Nodes – EID-to-RLOC mappings (if you don´t expect many updates) – xTR does NOT need a Map-Server

We plan to deploy it in LISP-Beta

35

SLIDE 36

Prototype

Map-Request

Mappings Mappings

Map-Reply

xTR

LISP Flow Mappings New mappings Hyperledger P2P network Java SDK New mappings Validate

36

SLIDE 37

A Blockchain-based Mapping System

IETF 98 – Chicago March 2017

Jordi Paillissé, Albert Cabellos, Vina Ermagan, Fabio Maino

acabello@ac.upc.edu

htup://openoverlayrouter.org

37

SLIDE 38

More about the Consensus Algorithm

Rules used by nodes to agree on which data to accept
Eg. Bitcoin uses Proof of Work
Miners compute Proof of Work

– Finding a nonce that when added to the data makes its hash start with N zeros. – Hard

Other algorithms are being explored:

– Proof of Stake: nodes with more assets are more likely to add blocks – Practjcal Byzantjne Fault Tolerant: reach a minimum number of endorsements from nodes in order to add data – Deposit-based: assets are lost if a node performs an illegal operatjon (security deposit)

38

htups://www.linkedin.com/pulse/consensus-mechanisms-used-blockchain-ronald-chan