network security via explicit consent michael walfish the university of texas at austin
Post on 21-Dec-2015
214 Views
Preview:
TRANSCRIPT
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: 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
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 collaborators
• David Mazières, Stanford University
• Jad Naous, Stanford University
• Antonio Nicolosi, Stevens Institute of Technology
• Scott Shenker, UC Berkeley and ICSI
top related