Transcript Ethane: Addressing the Protection Problem in Enterprise

Ethane: Addressing the Protection
Problem in Enterprise Networks
Martin Casado
Michael Freedman
Glen Gibb
Lew Glendenning
Dan Boneh
Nick McKeown
Scott Shenker
Gregory Watson
Presented By: Martin Casado
PhD Student in Computer Science,
Stanford University
[email protected]
http://www.stanford.edu/~casado
June, 2006
Stanford 2006
Goal
Design network where connectivity is governed
by high-level, global policy
“Nick can talk to Martin using IM”
“marketing can use http via web proxy”
“Administrator can access everything”
“Traffic from secret access point cannot share infrastructure
with traffic from open access point”
June, 2006
Stanford 2006
Two Main Challenges
Provide a secure namespace for the policy
Design mechanism to enforce policy
June, 2006
Stanford 2006
Goal: Provide Secure Namespace
Policy declared over network namespace
(e.g. martin, machine-a, proxy, building1)
Words from namespace generally represent
physical things
(users, hosts, groups, access points)
Or at times, virtual things
(e.g. services, protocol, QoS classes)
“Nick can talk to Martin using IM”
“nity.stanford.edu can access dev-machines”
“marketing can use http via web proxy”
“Administrator can access everything”
June, 2006
Stanford 2006
Today’s Namespace
Lots of names in network namespace today




Hosts
Users
Services
Protocols
 Names are generally bound to network realities
(e.g. DNS names are bound to IP addresses)
 Often are multiple bindings that map a name to the entity
it represents (DNS -> IP -> MAC -> Physical Machine)
June, 2006
Stanford 2006
Problem with Bindings Today
•Goal: map “hostname” to physical “host”
Host Name
But!!!
•What if attacker can interpose between any of
the bindings?
(e.g. change IP/MAC binding)
IP
MAC
Physical Interface
•What if bindings change dynamically?
(e.g. DHCP lease is up)
•Or physical network changes?
Host
MAC
Physical Interface
June, 2006
Host
Stanford 2006
Examples of Problems Today are
LEGION
ARP is unauthenticated
(attacker can map IP to wrong MAC)
DHCP is unauthenticated
(attacker can map gateway to wrong IP)
DNS caches aren’t invalidate as DHCP
lease times come up (or clients leave)
Security filters aren’t often invalidated
with permission changes
Many others …
June, 2006
Stanford 2006
Need “Secure Bindings”
1. Bindings are authenticated
2. Cached bindings are appropriately
invalidated
 Address reallocation
 Topology change
 Permissions changes/Revocation
June, 2006
Stanford 2006
Why Not Statically Bind?
This is very commonly done!
E.g.
Static ARP cache to/from gateway
MAC addresses tied to switch ports
Static IP allocations
Static rules for VLAN tagging
Results in crummy (inflexible) networks
June, 2006
Stanford 2006
Two Main Challenges
Provide a namespace for the policy
Design Mechanism to Enforce Policy
June, 2006
Stanford 2006
Policy Language
Declare connectivity constraints over
 Users/groups
 Hosts/Nodes
 Access points
 Protocols
 Services
Connectivity constraints are …
 Permit/deny
 Require middlebox interposition
 Isolation
 Physical security
June, 2006
Stanford 2006
Threat Environment
Suitable for use in .mil, .gov, .com and .edu
Insider attack
Compromised machines
Targeted attacks
yet …
Flexible enough for use in open environments
June, 2006
Stanford 2006
Our Solution: Ethane
Flow-based network
Central Domain Controller (DC)





Implements secure bindings
Authenticates users, hosts, services, …
Contains global security policy
Checks every new flow against security policy
Decides the route for each flow
Access is granted to a flow
 Can enforce permit/deny
 Can enforce middle-box interposition constraints
 Can enforce isolation constraints
June, 2006
Stanford 2006
Ethane: High-Level Operation
Host
authenticate
User
authentication
Send
tcp
SYN packet
•Permission check
•RouteHost
computation
Authentication
Authentication
Domain Controller User
“hi, I’m host
A, my password is …
?
hi,
I’m
host
B,password
my password
is …
hi,to
I’mhost
Nick,
Amy
port
2525 is
Can I have an IP?
Network Policy
“can
hi, I’m
martin,
password is”
I have
an IPmy
address?”
“Nick can access Martin using ICQ”
Host B
Secure Binding State
ICQ → 2525/tcp
Host A → IP 1.2.3.4
IP 1.2.3.4 → switch3 port 4
Martin → Host A
Host B → IP 1.2.3.5
IP 1.2.3.5 → switch 1 port 2
NickJune, 2006
→ HostB
Host A
Stanford 2006
Some Cool Consequences
 Don’t have to maintain consistency of distributed access control lists
 DC picks route for every flow
 Can interpose middle-boxes on route
 Can isolate flow to be within physical boundaries
 Can isolate two sets of flows to traverse different switches
 Can load balance requests over different routes
 DC determines how a switch processes a flow
 Different queue, priority classes, QoS, etc
 Rate limit a flow
 Amount of flow state is not a function of the network policy
 Forwarding complexity is not a function of the network policy
 Anti-mobility: can limit machines to particular physical ports
 Can apply policy to network diagnostics
June, 2006
Stanford 2006
Many Unanswered Questions
How do you bootstrap securely?
How is forwarding accomplished?
What are the performance implications?
June, 2006
Stanford 2006
Component Overview
•Send topology information to the DC
•Provide default connectivity to the DC
Domain
•Enforce paths created
byController
DC
•Handle flow revocation
•Specify access controls
•Request access to services
Switches
•Authenticates users/switches/end-hosts
•Manages secure bindings
•Contains network topology
•Does permissions checking
•Computes routes
End-Hosts
June, 2006
Stanford 2006
Bootstrapping
Finding the DC
Authentication
Generating topology at DC
June, 2006
Stanford 2006
Assumptions
DC knows all switches and their public
keys
All switches know DC’s public key
June, 2006
Stanford 2006
Finding the DC
Switches construct spanning
0
tree Rooted at DC
Switches don’t advertise
1
path to DC until they’ve
1
2
authenticated
Once authenticated, switches
pass all traffic without flow entries
to the DC
(next slide)
June, 2006
Stanford 2006
0
1
2
2
Initial Traffic to DC
2
June, 2006
Stanford 2006
Initial Traffic to DC
All packets to the DC (except first hop switch)
are tunneled
Tunneling includes incoming port
DC can shut off malicious packet sources
June, 2006
Stanford 2006
Establishing Topology
Ksw1
Ksw2
Ksw3
Ksw4
Switches generate neighbor lists
K
during MST algorithm
Send encrypted neighbor-list
K
to DC
DC aggregates to full topology
sw1
sw2
Note: no switch knows full topology
June, 2006
Stanford 2006
Ksw4
Ksw3
Forwarding = Really simple
Each switch maintains flow table
Only DC can add entry to flow table
Flow lookup is over:
in port, ether proto, src ip, dst ip, src port, dst port
out port
June, 2006
Stanford 2006
Detailed Connection Setup
? DC
 Switches disallow all Ethernet broadcast
(and respond to ARP for all IPs)
<src,dst,sprt,dprt>
 First packet of every new flow is sent
to DC for permission check
<ARP reply>
 DC sets up flow at each switch
 Packets of established flows are
forwarded using multi-layer
switching
<src,dst,sprt,dprt>
Alice
June, 2006
Stanford 2006
Bob
Performance
Decouple control and data path in switches
Software control path (connection setup)
(slightly higher latency)
 DC can handle complicated policy
 Switches just forward
(very simple datapath)
Simple, fast, hardware forwarding path
(Gigabits)
 Single exact-match lookup per packet
June, 2006
Stanford 2006
Permission Check per Flow?
Exists today, sort of .. (DNS)
Paths can be long lived
(used by multiple transport-level flows)
Permission check is fast
Replicate DC
 Computationally (multiple servers)
 Topologically (multiple servers in multiple places)
June, 2006
Stanford 2006
Implementation Goals
Support multiple deployments with varying
policy requirements
 first deployment by Oct. 31rst
 Remote deployment by Nov. 15th
Backwards compatible, no modification to endhosts
1k - 5k requests per second
Control path in software
Data path in hardware (gigabit speeds)
June, 2006
Stanford 2006
Implementation Status
Switches implemented on multi-port PCs
Bootstrapping, flow-setup and software
forwarding completed
Switches currently deployed and supporting
traffic of 16 hosts
June, 2006
Stanford 2006
Prototyping Strategy
Use simple 2-port switches
(bumps)
On links between
Ethernet switches
June, 2006
Stanford 2006
Questions?
June, 2006
Stanford 2006