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

2. 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”
Everyone knows it is broken … don’t want to belaber the point
Just want to focus on what exactly is wrong.
The whole goal here is simple and conservative network design (focused on attack resistance)
Access Controls (not admissions control)

3. Two Main Challenges Provide a secure namespace for the policy
Design mechanism to enforce policy
Focus on negative affects protection measures have on edge networks

4. 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)
Focus on negative affects protection measures have on edge networks
“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”

5. 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)
Focus on negative affects protection measures have on edge networks

6. Problem with Bindings Today
Goal: map “hostname” to physical “host”
But!!!
What if attacker can interpose between any of the bindings? (e.g. change IP/MAC binding)
What if bindings change dynamically? (e.g. DHCP lease is up)
Or physical network changes?
Host Name IP
MAC
Physical Interface
Host
MAC
Physical Interface
Host

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

8. Need “Secure Bindings”
Bindings are authenticated
Cached bindings are appropriately invalidated
Address reallocation
Topology change
Permissions changes/Revocation
Network is a bunch of tables/state that contain mappings between names, addresses and physical entities

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

10. Two Main Challenges Provide a namespace for the policy
Design Mechanism to Enforce Policy
Focus on negative affects protection measures have on edge networks

11. 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
Everyone knows it is broken … don’t want to belaber the point
Just want to focus on what exactly is wrong.
The whole goal here is simple and conservative network design (focused on attack resistance)
Access Controls (not admissions control)

12. 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
Focus on negative affects protection measures have on edge networks

13. 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
Focus on negative affects protection measures have on edge networks

14. Ethane: High-Level Operation
Permission check
Route computation ?
Host Authentication “hi, I’m host A, my password is … can I have an IP address?”
User authentication hi, I’m Nick, my password is
Host authenticate hi, I’m host B, my password is …
Can I have an IP?
User Authentication “hi, I’m martin, my password is”
Domain Controller
Send tcp SYN packet to host A port 2525
Network Policy
“Nick can access Martin using ICQ”
Host B
Secure Binding State
ICQ → /tcp IP
switch3 port 4
Host A IP
switch 1 port 2
HostB
Start off at a very high level, and then drill down into the details
I claim now and will support it in the following slides that:
We can do this efficiently
And in a backwards compatible fashin
And support very large networks
Host A →
IP →
Martin →
Host B →
IP →
Nick →
Host A

15. 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
Default connectivity  only to the DC

16. Many Unanswered Questions
How do you bootstrap securely?
How is forwarding accomplished?
What are the performance implications?
Decntralized trust -> know where to put man with gun
(XXX: make sure these are symmetric with the problems with IP)

17. Component Overview Send topology information to the DC
Provide default connectivity to the DC
Enforce paths created by DC
Handle flow revocation
Domain Controller
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

18. Bootstrapping Finding the DC Authentication Generating topology at DC
Decntralized trust -> know where to put man with gun
(XXX: make sure these are symmetric with the problems with IP)

19. Assumptions DC knows all switches and their public keys
All switches know DC’s public key
Decntralized trust -> know where to put man with gun
(XXX: make sure these are symmetric with the problems with IP)

20. Finding the DC Switches construct spanning tree Rooted at DC
Switches don’t advertise path to DC until they’ve authenticated
Once authenticated, switches pass all traffic without flow entries to the DC (next slide) 1 1 1 2 2
Now I’m going to talk more about the mechanics of how all this works 2

21. Initial Traffic to DC
Now I’m going to talk more about the mechanics of how all this works 2

22. 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
Now I’m going to talk more about the mechanics of how all this works

23. Establishing Topology
Ksw1
Ksw2
Ksw3
Ksw4
Switches generate neighbor lists during MST algorithm
Send encrypted neighbor-list to DC
DC aggregates to full topology
Note: no switch knows full topology

24. 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
Decntralized trust -> know where to put man with gun
(XXX: make sure these are symmetric with the problems with IP)
out port

25. Detailed Connection Setup?
Switches disallow all Ethernet broadcast (and respond to ARP for all IPs)
First packet of every new flow is sent to DC for permission check
DC sets up flow at each switch
Packets of established flows are forwarded using multi-layer switching DC
<src,dst,sprt,dprt>
<ARP reply>
- Really important, DC does not make the decision based on the source address in the packet, but
On the circuit it was forwarded from -
<ARP,bob>
<src,dst,sprt,dprt>
Alice
Bob

26. 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
Definitely simpler than per packet checks against large set of filters, rules, policies etc.

27. 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)
Most web re quests prec. by DNS….

28. Implementation Goals
Support multiple deployments with varying policy requirements
first deployment by Oct. 31rst
Remote deployment by Nov. 15th
Backwards compatible, no modification to end-hosts
1k - 5k requests per second
Control path in software
Data path in hardware (gigabit speeds)

29. Implementation Status
Switches implemented on multi-port PCs
Bootstrapping, flow-setup and software forwarding completed
Switches currently deployed and supporting traffic of 16 hosts

30. Prototyping Strategy Use simple 2-port switches (bumps)
On links between Ethernet switches
This is a concrete example of how our architecture works
A central server hands out capabilites as encrypted source routes
The source routes are used in the isolation layer
Bottom of the source route is transport address, allows fine grained access controls

31. Questions?
Broadly decompose Internet into public and private