Ethane: Addressing the Protection Problem in Enterprise Networks

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 casado@cs.stanford.edu http://www.stanford.edu/~casado

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”

3. Two Main Challenges • Provide a secure namespace for the policy • Design mechanism to enforce policy

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

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

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

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

12. Threat Environment • Suitable for use in .mil, .gov, .com and .edu • Insider attack • Compromised machines • Targeted attacksyet … • Flexible enough for use in open environments

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

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 martin, my password is” Host authenticatehi, I’m host B, my password is … Can I have an IP? Domain Controller User authenticationhi, I’m Nick, my password is Send tcp SYN packetto host A port 2525 Network Policy “Nick can access Martin using ICQ” Host B Secure Binding State ICQ→ 2525/tcp IP 1.2.3.4 switch3 port 4 Host A IP 1.2.3.5 switch 1 port 2 HostB Host A → IP 1.2.3.4 → Martin→ Host B → IP 1.2.3.5 → 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

16. Many Unanswered Questions • How do you bootstrap securely? • How is forwarding accomplished? • What are the performance implications?

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

19. Assumptions • DC knows all switches and their public keys • All switches know DC’s public key

20. Finding the DC • Switches construct spanning tree Rooted at DC • Switches don’t advertisepath to DC until they’veauthenticated • Once authenticated, switchespass all traffic without flow entriesto the DC(next slide) 0 0 1 1 1 2 2 2

21. Initial Traffic to DC 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

23. Ksw4 Ksw1 Ksw3 Ksw2 Ksw1 Ksw2 Ksw3 Ksw4 Establishing Topology • Switches generate neighbor listsduring MST algorithm • Send encrypted neighbor-listto 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 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 sentto DC for permission check • DC sets up flow at each switch • Packets of established flows areforwarded using multi-layerswitching DC <src,dst,sprt,dprt> <ARP reply> <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

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)

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

31. Questions?