Network Security via Explicit Consent Michael Walfish The

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 § 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

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

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)?

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

Many network-layer proposals and defenses • ACLs, NATs, VPNs, TVA, NUTSS, i 3, 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, …

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

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

Empowering all stakeholders: the principle of consent xoooooox oooxooooo oooooxoooo ooooxoo • 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

• 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? xoooooox oooxooooo oooooxoooo ooooxoo

Challenge: Enforcing as yet unknown policies. info , P= R 1, < C 1 , …> R 2 = ( C MA General-purpose servers , P) s r 1 knows sr 1 P C 1 C 2 data • Make authorization decisions prior to packet flow • Move policy from routers to evolvable servers • Servers can delegate or abdicate their control

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 C 1 C 2 V 1 V 2 data P C 1 C 2 data ? • Our ICING network architecture solves this problem with new packet authentication techniques

ICING is feasible • Space overhead? R 0 R 1 R 2 R 3 R 4 20 bytes (ECC) M 16 bytes § Average ICING header: ~250 bytes § Average packet size: ~1300 bytes [CAIDA] § So, total overhead from ICING: ~20% more space • What is the hardware cost? § Net. FPGA gate counts: ICING is 13. 4 M, IP is 8. 7 M § Net. FPGA forwarding speed: ICING is ~80% of IP § ICING compared to IP in gates/(Gbits/sec): ~2 x

• What does it actually mean for a flow to be authorized? (A: principle of consent. ) xoooooox oooxooooo oooooxoooo ooooxoo • How can we enforce the principle of consent? (A: with our ICING network architecture. ) • How can we use ICING to mitigate specific threats?

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

Example use: offsite scrubbing service P C consent server enterprise

Example use: choosing trustworthy providers through sink routing S C, P consent server • 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

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

Looking ahead…. .

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 Net. FPGA card per machine Managed by Emulab configuration software This is state-of-the-art: it is the largest Emulabenabled Net. FPGA deployment anywhere • Allows us to emulate medium-scale ICING networks

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

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

Acknowledgments and students

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

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