Firenet PhD semester project Jingyue Zhao Supervisors: Prof. Bryan - - PowerPoint PPT Presentation

▶
firenet phd semester project
SMART_READER_LITE
LIVE PREVIEW

Firenet PhD semester project Jingyue Zhao Supervisors: Prof. Bryan - - PowerPoint PPT Presentation

Dec 04, 2023 40 likes •346 views

Firenet PhD semester project Jingyue Zhao Supervisors: Prof. Bryan Ford, Prof. Katerina Argyraki Network Management 1 Network Management 2 Network Management 3 Motiv ivation Long-term goal: a transparent and secure decentralized

slide-1
SLIDE 1

Firenet – PhD semester project

Jingyue Zhao Supervisors: Prof. Bryan Ford, Prof. Katerina Argyraki

slide-2
SLIDE 2

Network Management

1

slide-3
SLIDE 3

Network Management

2

slide-4
SLIDE 4

Network Management

3

slide-5
SLIDE 5

Motiv ivation

  • Long-term goal: a transparent and secure decentralized network

management scheme for large-scale networks.

  • Decisions of each administrator direct or indirect impacts on other

parts of network.

  • Admins can be compromised  disaster of the entire network.

4

slide-6
SLIDE 6

System Model

  • A single small group of administrators make network policies together.
  • Follower routers correspond to SDN controllers which deploy the network policies.
  • Each network policy needs to be checked and approved by a threshold of admins to

avoid careless or malicious actions.

5

Follower routers Admins

slide-7
SLIDE 7

System Model

6

How to make the policy making process transparent and secure?

Follower routers Admins

  • A single small group of administrators make network policies together.
  • Follower routers correspond to SDN controllers which deploy the network policies.
  • Each network policy needs to be checked and approved by a threshold of admins to

avoid careless or malicious actions.

slide-8
SLIDE 8

System Model

7

Cothority Follower routers Admins

  • A single small group of administrators make network policies together.
  • Follower routers correspond to SDN controllers which deploy the network policies.
  • Each network policy needs to be checked and approved by a threshold of admins to

avoid careless or malicious actions.

slide-9
SLIDE 9

Cothority

  • Collective authority: a set of witness servers called conodes that collectively

execute decentralized protocols

  • Provide services: collective signing (CoSi [1]), Byzantine agreement, or generation
  • f public-randomness

8

Cothority

[1] Syta E, Tamas I, Visher D, et al. Keeping authorities" honest or bust" with decentralized witness cosigning[C]//Security and Privacy (SP), 2016 IEEE Symposium on. Ieee, 2016: 526-545.

slide-10
SLIDE 10

Threat Model

  • Network administrators: make and approve network policies
  • Malicious: propose or approve bad policies; only a threshold of admins can be compromised by an

attacker

  • Cothority (witness servers): check and track admins’ policy making process
  • Honest
  • Follower routers: pull and deploy the network policies periodically
  • Honest

9

Cothority Follower routers Admins

slide-11
SLIDE 11

Design of f Fir irenet

Step 1: admins’ approval

Network policy

Admins

10

Follower routers

Key 1 Key 2 Key 4 Key 3

slide-12
SLIDE 12

Network policy Admin signatures

Admins

11

Design of f Fir irenet

Step 1: admins’ approval

Follower routers

Key 1 Key 2 Key 4 Key 3

slide-13
SLIDE 13

Network policy Config file Admin signatures 12

Design of f Fir irenet

Step 1: admins’ approval

Follower routers

Admins

Key 1 Key 2 Key 4 Key 3

slide-14
SLIDE 14

Network policy Config file Admin signatures 13

Design of f Fir irenet

Step 1: admins’ approval

Follower routers

Verify admins’ signatures & deploy the policy Admins

Key 1 Key 2 Key 4 Key 3

slide-15
SLIDE 15

Network policy Config file Admin signatures

Admins

14

Design of f Fir irenet

Step 2: cothority’s approval check and collective signing

Cothority

Follower routers

For now, the check is done by one server in the cothority, and we can design a protocol to distribute the workload.

slide-16
SLIDE 16

Network policy Config file Admin signatures

Admins

15

Design of f Fir irenet

Step 2: cothority’s approval check and collective signing (using CoSi [1])

Cothority

Network policy Config file Collective signature [1] Syta E, Tamas I, Visher D, et al. Keeping authorities" honest or bust" with decentralized witness cosigning[C]//Security and Privacy (SP), 2016 IEEE Symposium on. Ieee, 2016: 526-545.

Follower routers

slide-17
SLIDE 17

Network policy Config file Admin signatures

Admins

16

Design of f Fir irenet

Step 2: cothority’s approval check and collective signing

Cothority

Network policy Config file Collective signature

Follower routers

Verify one single co-signature & deploy the policy

slide-18
SLIDE 18

Network policy Config file Previous block hash Admin signatures

Admins

17

Design of f Fir irenet

Step 3: cothority’s appending the new policy to the chain (using Skipchain[2])

Cothority

Network policy Config

Collective signature

Block hash 1 Random ID Network policy Config Collective signature Network policy Config

Collective signature

Previous block hash Block hash 2

Follower routers

[2] Nikitin K, Kokoris-Kogias L, Jovanovic P, et al. CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds[J]. 2017.

slide-19
SLIDE 19

Admins

18

Design of f Fir irenet

Step 3: cothority’s appending the new policy to the chain

Cothority

Network policy Config

Collective signature

Block hash 1 Random ID Network policy Config Collective signature Network policy Config

Collective signature

Previous block hash Block hash 2 Network policy Config

Collective signature

Previous block hash Block hash 3

Follower routers

slide-20
SLIDE 20

Admins

19

Design of f Fir irenet

Step 3: cothority’s appending the new policy to the chain

Cothority

Network policy Config

Collective signature

Block hash 1 Random ID Network policy Config Collective signature Network policy Config

Collective signature

Previous block hash Block hash 2 Network policy Config

Collective signature

Previous block hash Block hash 3

Follower routers

slide-21
SLIDE 21

Admins

20

Design of f Fir irenet

Step 3: cothority’s appending the new policy to the chain

Cothority

Network policy Config

Collective signature

Block hash 1 Random ID Network policy Config Collective signature Network policy Config

Collective signature

Previous block hash Block hash 2 Network policy Config

Collective signature

Previous block hash Block hash 3

Follower routers

slide-22
SLIDE 22

21

Fir irenet in 1 slide

Admins Cothority

Network policy Config

Collective signature

Block hash 1 Random ID Network policy Config Collective signature Network policy Config

Collective signature

Previous block hash Block hash 2 Network policy Config

Collective signature

Previous block hash Block hash 3

Follower routers

Network policy Config file Previous block hash Admin signatures

Step 4: Follower routers’ downloading, verifying & deploying the latest policy periodically Step 1: Admins’ policy proposal & approval Step 2: Cothority’s approval check & co-signature Step 3: Cothority’s appending new policy to the chain

slide-23
SLIDE 23

Network Policy Description Language

Property Value Matches Chain INPUT, OUTPUT, FORWARD Protocol TCP, UDP, ICMP, ALL Source IP/network x.x.x.x, x.x.x.x/x, ALL Source ports Port number(s) Destination IP/network x.x.x.x, x.x.x.x/x, ALL Destination ports Port number(s) Action ACCEPT, DROP, REJECT

  • Based on Linux iptables
  • One network policy consists of several network rules
  • One policy is self-sufficient
  • JSON object

22 Property Value Policy description string Number of network rules int An array of network rules Network rule 1 Network rule 2 … Network rule n

Network policy Network rule

slide-24
SLIDE 24

Im Implementation

  • Firenet is implemented in Go
  • Based on the Cothority framework, using CoSi and Skipchain
  • 1.3kLOC
  • Main functions with APIs
  • Genesis Policy Request
  • New Policy Request
  • Get Policy Request
  • Verify Policy Request

23

slide-25
SLIDE 25

Evaluation

24

Testbed: 32-core Intel Xeon CPU at 2.6 GHz with 66GB of RAM (one server of IC cluster)

Maximum 0.18 sec for 100 admins Maximum 20.8 sec for 128 conodes

slide-26
SLIDE 26

Evaluation

25 ApprovalCheck 0% CoSign 20% CreateBlock 80%

  • thers

0%

Genesis policy CPU time component (50 admins, 128 conodes)

ApprovalCheck CoSign CreateBlock

  • thers

ApprovalCheck 0% CoSign 8% CreateBlock 0% StoreBlock 92%

  • thers

0%

New policy CPU time component (50 admins, 128 conodes)

ApprovalCheck CoSign CreateBlock StoreBlock

  • thers

Time cost component

slide-27
SLIDE 27

Compared to SDN

  • Follower routers can be seen as SDN controllers
  • Security-enhanced SDN application layer
  • Easy to rollback to a previous correct network configuration

26 [3] https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/

slide-28
SLIDE 28

Future Work

  • Performance evaluation & analysis
  • Tendency and limit
  • Bandwidth
  • Time cost vs number of policies
  • Protocol improvement
  • Multiple groups of admins
  • Hierarchical network policy

27

slide-29
SLIDE 29

Thank you!

28

slide-30
SLIDE 30

Im Implementation

NM APP NM APP (leader) NM APP admins NM service NM service NM service

Genesis Policy Request, New Policy Request

Validate the new policy block & append it to the chain FR APP FR APP FR APP follower routers

Get Policy Request, Verify Policy Request

Return the latest policy & validate its co-signature conodes Protocols Calling Cosi + Skipchain API push Network policy skipchain pull NM service

29