network security via explicit consent
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/1.jpg)
Network Security via Explicit Consent
Michael WalfishThe University of Texas at Austin
![Page 2: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/2.jpg)
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
![Page 3: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/3.jpg)
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.)
![Page 4: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/4.jpg)
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)?
![Page 5: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/5.jpg)
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?
![Page 6: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/6.jpg)
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, …
![Page 7: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/7.jpg)
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]
![Page 8: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/8.jpg)
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
![Page 9: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/9.jpg)
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
![Page 10: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/10.jpg)
• 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
![Page 11: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/11.jpg)
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
![Page 12: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/12.jpg)
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 ?
![Page 13: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/13.jpg)
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
![Page 14: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/14.jpg)
• 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
![Page 15: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/15.jpg)
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
![Page 16: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/16.jpg)
Example use: offsite scrubbing service
P consent
server
enterprise
C
![Page 17: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/17.jpg)
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
![Page 18: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/18.jpg)
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
![Page 19: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/19.jpg)
Looking ahead…..
![Page 20: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/20.jpg)
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
![Page 21: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/21.jpg)
• 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)
![Page 22: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/22.jpg)
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
![Page 23: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/23.jpg)
Acknowledgments and students
![Page 24: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/24.jpg)
Acknowledgments and collaborators
• David Mazières, Stanford University
• Jad Naous, Stanford University
• Antonio Nicolosi, Stevens Institute of Technology
• Scott Shenker, UC Berkeley and ICSI
![Page 25: Network Security via Explicit Consent](https://reader036.vdocuments.us/reader036/viewer/2022081514/568147ae550346895db4ef3e/html5/thumbnails/25.jpg)
Supported UT Austin students
• Joshua Leners (Overload management)
• Arun Seehra (Consent-based network architecture)
• Srinath Setty (Untrustworthy storage)