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

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)

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

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”

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

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

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 …

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

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

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

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)

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

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

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 → 2525/tcp IP 1.2.3.4 switch3 port 4 Host A IP 1.2.3.5 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 1.2.3.4 → Martin → Host B → IP 1.2.3.5 → Nick → Host A

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

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)

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

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)

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)

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

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

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

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

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

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

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.

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

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)

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

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

Questions? Broadly decompose Internet into public and private