Network Security via Explicit Consent

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)