Ethane

1. Ethane

2. Security and You • What does security mean to you? • Data on personal PC? • Data on family PC? • How do you implement these policies?

3. Enterprise Security • How does this defer in the enterprise setting? • Current approach • Difficult to express policies • Policies are easily broken or circumvented

4. 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”

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

6. 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”

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

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

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

10. Need “Secure Bindings” • Bindings are authenticated • Cached bindings are appropriately invalidated • Address reallocation • Topology change • Permissions changes/Revocation

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

12. Two Main Challenges • Provide a namespace for the policy • Design Mechanism to Enforce Policy

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

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

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

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

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

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

19. Component Overview • Send topology information to the DC • Provide default connectivity to the DC • Enforce paths created by DC • Handle flow revocation Domain Controller • Request access to services Switches • Authenticates users/switches/end-hosts • Manages secure bindings • Contains network topology • Does permissions checking • Computes routes End-Hosts

20. Bootstrapping • Finding the DC • Authentication • Generating topology at DC

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

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

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. Establishing Topology 2

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

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

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

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

29. 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)

30. Ethane Summary • Current networks insecure and difficult to manage • Useless namespace • Topology encoded in config • Ethane addresses issues via architectural changes • Centralized • Authenticated bindings • “default off”

31. Questions?