firenet phd semester project
play

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

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


  1. Firenet – PhD semester project Jingyue Zhao Supervisors: Prof. Bryan Ford, Prof. Katerina Argyraki

  2. Network Management 1

  3. Network Management 2

  4. Network Management 3

  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

  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. Follower routers Admins 5

  7. 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. Follower routers How to make the policy making process transparent and secure? Admins 6

  8. 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. Follower routers Cothority Admins 7

  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 of public-randomness 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. 8

  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’ p olicy making process • Honest • Follower routers: pull and deploy the network policies periodically • Honest Follower routers Cothority Admins 9

  11. Design of f Fir irenet Step 1: admins’ approval Key 1 Follower routers Key 2 Network policy Key 3 Key 4 Admins 10

  12. Design of f Fir irenet Step 1: admins’ approval Key 1 Follower routers Key 2 Network policy Admin signatures Key 3 Key 4 Admins 11

  13. Design of f Fir irenet Step 1: admins’ approval Key 1 Follower routers Network policy Key 2 Config file Admin signatures Key 3 Key 4 Admins 12

  14. Design of f Fir irenet Step 1: admins’ approval Key 1 Follower routers Network policy Key 2 Config file Admin signatures Key 3 Verify admins’ Key 4 signatures & Admins deploy the policy 13

  15. Design of f Fir irenet Step 2: cothority’s approval check and collective signing Follower routers Network policy Config file Admin signatures Cothority Admins For now, the check is done by one server in the cothority, and we can design a protocol to distribute the workload. 14

  16. Design of f Fir irenet Step 2: cothority’s approval check and collective signing (using CoSi [1]) Follower routers Network policy Network policy Config file Config file Admin signatures Collective signature Cothority Admins [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. 15

  17. Design of f Fir irenet Step 2: cothority’s approval check and collective signing Follower routers Network policy Network policy Config file Config file Admin signatures Collective signature Verify one single co-signature & Cothority deploy the policy Admins 16

  18. Design of f Fir irenet Step 3: cothority’s appending the new policy to the chain (using Skipchain[2]) 2 1 Block hash Block hash Network policy Config file Network policy Network policy Network policy Config Config Config Previous block hash Collective signature Collective signature Collective signature Admin signatures Random ID Previous block hash Cothority Admins 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. 17

  19. Design of f Fir irenet Step 3: cothority’s appending the new policy to the chain 2 1 Block hash Block hash Network policy Network policy Network policy Config Config Config Collective signature Collective signature Collective signature Random ID Previous block hash Cothority Admins Follower routers 3 Block hash Network policy Config Collective signature Previous block hash 18

  20. Design of f Fir irenet Step 3: cothority’s appending the new policy to the chain 2 1 Block hash Block hash 3 Block hash Network policy Network policy Network policy Network policy Config Config Config Config Collective signature Collective signature Collective signature Collective signature Random ID Previous block hash Previous block hash Cothority Admins Follower routers 19

  21. Design of f Fir irenet Step 3: cothority’s appending the new policy to the chain 2 1 Block hash Block hash 3 Block hash Network policy Network policy Network policy Network policy Config Config Config Config Collective signature Collective signature Collective signature Collective signature Random ID Previous block hash Previous block hash Cothority Admins Follower routers 20

  22. Fir irenet in 1 slide 2 1 Block hash Block hash 3 Block hash Network policy Config file Network policy Network policy Network policy Network policy Config Config Config Config Previous block hash Collective signature Collective signature Collective signature Collective signature Admin signatures Random ID Previous block hash Previous block hash Step 1: Admins’ Step 3: Step 2: policy proposal Cothority’s appending Cothority’s approval & approval Cothority check & co-signature new policy to the chain Admins Follower routers Step 4: Follower routers’ downloading, verifying & deploying the latest policy periodically 21

  23. Network Policy Description Language • Based on Linux iptables • One network policy consists of several network rules • One policy is self-sufficient • JSON object Network rule Property Value Network policy Matches Chain INPUT, OUTPUT, FORWARD Protocol TCP, UDP, ICMP, ALL Property Value Source IP/network x.x.x.x, x.x.x.x/x, ALL Policy description string Source ports Port number(s) Number of network rules int Destination x.x.x.x, x.x.x.x/x, ALL An array of network rules Network rule 1 IP/network Network rule 2 Destination ports Port number(s) … Action ACCEPT, DROP, REJECT Network rule n 22

  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

  25. Evaluation 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 24

  26. Evaluation Time cost component Genesis policy CPU time component (50 admins, 128 conodes) New policy CPU time component (50 admins, 128 conodes) ApprovalCheck CoSign CoSign ApprovalCheck 0% 8% 20% 0% others 0% CreateBlock others 0% 0% StoreBlock 92% CreateBlock 80% ApprovalCheck CoSign CreateBlock others ApprovalCheck CoSign CreateBlock StoreBlock others 25

  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/

  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

  29. Thank you! 28

  30. Im Implementation Return the latest policy & Validate the new policy block & validate its co-signature append it to the chain NM NM NM NM NM FR APP service APP service service service Genesis Policy Request, NM APP New Policy Request FR APP (leader) Get Policy Request, Calling Cosi + Skipchain API Verify Policy Request NM FR APP Protocols APP pull push admins follower routers Network policy skipchain conodes 29

Recommend


More recommend