Network Security via Explicit Consent Michael Walfish The University of Texas at Austin.

Network Security via Explicit Consent

Michael WalfishThe 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

scrubbing

service• Which stakeholders should have control?

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, …

Prior works: incomplete and incompatible

x o o o o o

source routing o - - - - x

Capabilitieso x o - - oo - - o x o

NUTSS

Auth. routing- - - o x o

- - o x o -- o x o - -o x o - - -

Secure BGP- - - o x o- - o x o o- o x o o oo x o o o o

Filterso - - - x oo - - x - oo - x - - oo x - - - o

• The “boxes” don’t generally compose

[legend: each row is a control; within the row, x constrains o]

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

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o 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

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

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

Challenge: Enforcing as yet unknown policies

General-purpose servers

P = <R

1,R2,…

>, inf

o.

C1 =

MAC(sr1

, P)

knows sr1

P C1 C2

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

P C1 C2

data

• 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.

• Our ICING network architecture solves this problem with new packet authentication techniques

P C1 C2 V1 V2 data ?

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

R0 R1 R2 R3 R4 M

20 bytes (ECC) 16 bytes

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

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

Example use: preventing denial-of-service

P

consent

server

• Consent-granting delegated to high-bandwidth DoS-prevention specialist

• Alternate: give special clients (e.g., employees) ability to mint permissions

C

C

employee

Example use: offsite scrubbing service

P consent

server

enterprise

C

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

• 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

Further work needed (experimental and design)

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)