1. June, 2006 Stanford 2006 Ethane

2. June, 2006 Stanford 2006 Security and You  What does security mean to you?  Data on personal PC?  Data on family PC?  How do you implement these policies?

3. June, 2006 Stanford 2006 Enterprise Security  How does this defer in the enterprise setting?  Current approach  Difficult to express policies  Policies are easily broken or circumvented

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

5. June, 2006 Stanford 2006 Two Main Challenges  Provide a secure namespace for the policy  Design mechanism to enforce policy

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

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

8. June, 2006 Stanford 2006 Problem with Bindings Today Host Name IP MAC Physical Interface 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 MAC Physical Interface Host

9. June, 2006 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 …

10. June, 2006 Stanford 2006 Need “Secure Bindings” 1.Bindings are authenticated 2.Cached bindings are appropriately invalidated  Address reallocation  Topology change  Permissions changes/Revocation

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

12. June, 2006 Stanford 2006 Two Main Challenges  Provide a namespace for the policy  Design Mechanism to Enforce Policy

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

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

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

16. June, 2006 Stanford 2006 Host authenticate hi, I’m host B, my password is … Can I have an IP? Send tcp SYN packet to host A port 2525 User Authentication “ hi, I’m martin, my password is” Ethane: High-Level Operation Domain Controller Host A Host Authentication “ hi, I’m host A, my password is … can I have an IP address?” Host B User authentication hi, I’m Nick, my password is ? Permission check Route computation 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 Network Policy “Nick can access Martin using ICQ” Host A → IP 1.2.3.4 → Martin → Host B → IP 1.2.3.5 → Nick →

17. June, 2006 Stanford 2006  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 Some Cool Consequences

18. June, 2006 Stanford 2006  How do you bootstrap securely?  How is forwarding accomplished?  What are the performance implications? Many Unanswered Questions

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

20. June, 2006 Stanford 2006  Finding the DC  Authentication  Generating topology at DC Bootstrapping

21. June, 2006 Stanford 2006  DC knows all switches and their public keys  All switches know DC’s public key Assumptions

22. June, 2006 Stanford 2006 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) 0 0 1 1 1 2 2 2

23. June, 2006 Stanford 2006 Establishing Topology  Switches generate neighbor lists during MST algorithm  Send encrypted neighbor-list to DC  DC aggregates to full topology  Note: no switch knows full topology K sw1 K sw2 K sw3 K sw4 K sw1 K sw3 K sw4 K sw2

24. June, 2006 Stanford 2006 Establishing Topology 2

25. June, 2006 Stanford 2006  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 Forwarding = Really simple out port

26. June, 2006 Stanford 2006  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 AliceBob ? Detailed Connection Setup

27. June, 2006 Stanford 2006 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. June, 2006 Stanford 2006  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 Performance

29. June, 2006 Stanford 2006  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) Permission Check per Flow?

30. June, 2006 Stanford 2006 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. June, 2006 Stanford 2006 Questions?