1 / 25

Network Security via Explicit Consent

Network Security via Explicit Consent. Michael Walfish The University of Texas at Austin. Botnets are not the problem. Botnets are a symptom Of things gone wrong with end-hosts and network Network is too permissive and too restrictive Innovation easy for attackers, hard for defenders

kayo
Download Presentation

Network Security via Explicit Consent

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. Network Security via Explicit Consent Michael Walfish The University of Texas at Austin

  2. Botnets are not the problem • Botnets are a symptom • Of things gone wrong with end-hosts and network • Network is too permissive and too restrictive • Innovation easy for attackers, hard for defenders • Defenses limited to what routers can check • We need to rearchitect and redesign the network • Minor changes will lead to … minor changes • Ancillary benefit of major changes: no botnet threat

  3. We start with two principles Be less permissive and less restrictive: • Disallow unauthorized flows • Make it easy for policies and defenses to evolve (We will add another.)

  4. Disallowing unauthorized flows The rest of this talk will be in three parts: • What does it actually mean for a flow to be authorized? • Who does the authorizing? Based on what? • How can we enforce this notion of authorized in a network architecture? • How can we use the architecture to mitigate specific threats (e.g., botnets)?

  5. There are many stakeholders in a network • Senders, receivers, transit providers, edge providers, middleboxes, … • Each has many policy- and security-related goals scrubbing service • Which stakeholders should have control?

  6. Many network-layer proposals and defenses • ACLs, NATs, VPNs, TVA, NUTSS, i3, DOA, NIRA, LSRR, firewalls, source routing, whitelisting, blacklisting, securing BGP, provider filtering based on sender, provider filtering based on receiver, signature matching, network capabilities, telephoning your ISP, telephoning your attacker’s ISP, …

  7. source routing xo o o o o Secure BGP NUTSS Capabilities Auth. routing Filters - -- o x o - -o x o o - o x o o o ox o o o o o x o - - o o - - ox o o - - - -x - -- o x o - - o x o - - o x o - - ox o - - - o ---x o o --x- o o -x - - o ox - - - o Prior works: incomplete and incompatible [legend: each row is a control; within the row, x constrains o] • The “boxes” don’t generally compose

  8. What are our options? • Embrace the status quo: do nothing • This is unsatisfactory • Make a hard choice: select the “right” subset • This would be a gamble … • … on a choice that might last another 30 years … • … by a community not known for accurate predictions • Choose “all of the above”:take a principled union • No guessing unknowables, no picking winners/losers • Most future-proof strategy possible

  9. Empowering all stakeholders:the principle of consent xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o • Permit a flow iff all on the path consent to the path • Can demand further information before consenting • This is a unified definition of network security • Subsumes goals of prior network-layer defenses • Obvious in hindsight

  10. xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o • What does it actually mean for a flow to be authorized? (A: principle of consent.) • How can we enforce the principle of consent in a network architecture? • Many challenges • This talk covers two of them • How can we use the architecture to mitigate specific threats?

  11. Challenge: Enforcing as yet unknown policies • Make authorization decisions prior to packet flow • Move policy from routers to evolvable servers • Servers can delegate or abdicate their control P = <R1,R2,…>, info. General-purpose servers C1 = MAC(sr1, P) knows sr1 P C1 C2 data

  12. Challenge: Constraining paths at high speed • Status quo not even close (BGP only advisory) • Target environment rules out previous techniques • Backbone speeds preclude digital signatures • Federated nature of Internet precludes central root of trust, pre-configured shared secrets, etc. P C1 C2 V1 V2 data ? P C1 C2 data • Our ICING network architecture solves this problem with new packet authentication techniques

  13. R0 R1 R2 R3 R4 M 16 bytes 20 bytes (ECC) ICING is feasible • Space overhead? • Average ICING header: ~250 bytes • Average packet size: ~1300 bytes [CAIDA] • So, total overhead from ICING: ~20% more space • What is the hardware cost? • NetFPGA gate counts: ICING is 13.4 M, IP is 8.7 M • NetFPGA forwarding speed: ICING is ~80% of IP • ICING compared to IP in gates/(Gbits/sec): ~2x

  14. What does it actually mean for a flow to be authorized? (A: principle of consent.) • How can we enforce the principle of consent? (A: with our ICING network architecture.) • How can we use ICING to mitigate specific threats? xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o

  15. Example use: preventing denial-of-service consent server • Consent-granting delegated to high-bandwidth DoS-prevention specialist • Alternate: give special clients (e.g., employees) ability to mint permissions C P employee C

  16. Example use: offsite scrubbing service P consent server C enterprise

  17. Example use: choosing trustworthy providers through sink routing • This is analog of well-known source routing • Sender requests consent; gives its own id (S) • Receiver specifies path toward itself • Useful for organizations handling sensitive data S consent server C, P

  18. ICING aids network defense more generally • ICING is flexible • Consent based on stakeholders’ policies • Fine-grained control reduces collateral damage • ICING is evolvable • Changing policy means updating only local software, not reconfiguring core routers • ICING is general • Incorporates the controls of other proposals … and provides their benefits

  19. Looking ahead…..

  20. Further work needed (experimental and design) • Our testbed is a key experimental apparatus • 25 server-class machines • Quad Core Intel Xeon processors, 8 GB RAM, … • 1 NetFPGA card per machine • Managed by Emulab configuration software • This is state-of-the-art: it is the largest Emulab-enabled NetFPGA deployment anywhere • Allows us to emulate medium-scale ICING networks

  21. Further work needed (experimental and design) • Assessing control plane overhead • Retrieving paths and consent • Route dissemination • Defending against intelligent replay attacks • Detecting unsatisfactory service by providers • Preventing unauthorized subcontracting of transit • E.g., prevent ISP from redirecting through country X

  22. Recapping our three questions • What does it mean for a flow to be authorized? • A: principle of consent  give all entities control • How can we enforce this principle? • A: With our ICING architecture • 100,000-foot view: bandwidth and computation keep increasing, so use them to buy new properties • Requires addressing challenging technical problems • How can we use ICING? • A: leads to natural defenses … • … and makes it easy to deploy new ones

  23. Acknowledgments and students

  24. Acknowledgments and collaborators • David Mazières, Stanford University • Jad Naous, Stanford University • Antonio Nicolosi, Stevens Institute of Technology • Scott Shenker, UC Berkeley and ICSI

  25. Supported UT Austin students • Joshua Leners (Overload management) • Arun Seehra (Consent-based network architecture) • Srinath Setty (Untrustworthy storage)

More Related