1 / 19

S tephan o s Matsu m o to S am u e l H i tz A d r ian Perrig

Fl eet: Defe ndin g SDNs fr o m M i s b e h av ing A d m ini stra t o rs. S tephan o s Matsu m o to S am u e l H i tz A d r ian Perrig. 1. Mo t iva t ion.  T he Misbeh aving Ad minis t r ato r Pr o bl em

vianca
Download Presentation

S tephan o s Matsu m o to S am u e l H i tz A d r ian Perrig

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fleet:DefendingSDNsfrom MisbehavingAdministrators Stephanos Matsumoto Samuel Hitz Adrian Perrig 1

  2. Motivation • The Misbehaving AdministratorProblem • Administrator affects SDNroutingbymisconfiguringa correctly functioningcontroller • Human error is responsible for50-­‐80%of all networkoutages [1] • Misconfigurations thatdo notcauseoutages can be difficult to detect [1] Juniper Networks. What’s behind network down time 2008.

  3. Contribution of the Paper • A definition, adversary model, and list of assumptions for the malicious administrator problem • Fleet, a controller architecture for the problem • A simulation and evaluation of the approaches • A discussion of future work and related problems

  4. Background and Related Work • Use Schnorrsignatures for threshold signatures • Use Shamir’s secret sharing scheme for splitting the threshold signature among administrators • Idea of distributed controllers • HyperFlow • Security enforcement controller • VerifFlow • FortNOX

  5. Problem Definition • Preventing k malicious administrators out of n total administrators from adversely affecting networking functions: • routing/forwarding, • recovery from failures, • availability in the network

  6. AdversaryModel • k misbehaving administrators (outof n total) • Networkconfigured to desired level of resilience • In practice,kwill be small (1or2) • May create policies selecting undesired paths • Cannot otherwiseaffectcontrolleroperation

  7. Assumptions • Switches pre-configured with necessarykeys • Administrators: • See the same network topology • Are looselytime-­-synchronized • Securelycommunicateout-of-band • Share the sameroutingpolicy if notmalicious

  8. Fleet'sApproach • The Fleet controllercontributes: • Threshold signaturefunctionalityto switches • Resilience byvoting on configurations • Orthogonal Approaches • Diversityof hardware/software[2] • Policy-­‐based flowrules [3,4] [2] DiegoKreutz, Fernando Ramos, and Paulo Verissimo. Towards secure and dependable soXware-­‐defined networks.HotSDN'13. [3] PhilipPorras et al. A securityenforcementkernel for OpenFlow networks. HotSDN'12. [4] AhmedKhurshid,et al. VeriFlow: Verifying network-­‐wide invariants in real time.HotSDN'12.

  9. FleetControllerArchitecture FleetController Intra-ControllerLinkController-SwitchLink AdministratorLayer Admin1Admin2 Admin3 SharedDataStorage SwitchIntelligenceLayer DataPlane (Switches/Links)

  10. RoutingwiththeFleetController • Single-configuration • Votingprotocol using threshold signatures • Multiple-configuration • Sources or ingress switches can select per-­‐flow routes

  11. Single-ConfigurationApproach • A threshold ‘t’ of administrators that must agree on a configuration in order to install it in the network. • t = k + 1; • Since t ≤ n − k, we can see that n ≥ 2k +1, ensuring that there is always a majority of non-malicious administrators Admin1 Admin2 Admin3 Admin4 Admin (n) Proposal

  12. Multi-Configuration Approach • Each administrator has its own routing configuration • Can construct it independently of the other administrators • Configurations then create a series of n routing planes in switch intelligence layer • But who should choose which routing plane to use and how? • The switch intelligence layer probabilistically choose a routing plane for each flow

  13. Drawbacks of Multi-Configuration • Switch intelligence needs to maintain greater information • Difficult to detect whether or not an administrator’s plane is violating guidelines • This approach is reactive rather than preventive

  14. Evaluation Prototypeimplementation in Python-­‐based POX controller and Mininet SDN framework Tested on randomtopologies of 20 switches and 50 hosts  Main question: whatdominates recoverytime?

  15. Evaluation Key size affects votingprotocol length Successful votetakes less than 1s 550 1024bit key 2048bit key 500 450 400 350 300 250 200 Time[ms] 150 4 5 6 7 8 Numberof Administrators 9 10

  16. Evaluation Link failure detection time dominates recovery 8 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 2.5 2 1.5 out of4admins malicious out of6admins malicious out of8admins malicious 4out of 10 admins malicious RecoveryTime [s] 1 1 2 3 4 Link Failure Detection Time[s] 5

  17. Factors affecting performance • Link failure detection time • Inter-administrator latency

  18. Future Work • Develop a method and series of metrics for evaluating routing planes • Explore the tradeoffs between maintaining availability and tolerating a greater number of malicious administrator • Data exfiltration

  19. Conclusions Fleet protects againstmisconfigurations with littleoverhead Switch intelligenceenables useful switch functionality,such as threshold signatures Companies can expand their networks to locations where admins may not be as trusted Thank you!Questions

More Related