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_at_cs.stanford.edu http//www.stanf
ord.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 everythingTraffic
  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
Todays 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 -gt IP -gt MAC -gt
  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 arent invalidate as DHCP lease times
  come up (or clients leave)
• Security filters arent 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 attacks
  yet
• 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 Authenticationhi, Im host A, my password
is can I have an IP address?
User Authenticationhi, Im martin, my password
is
Host authenticatehi, Im host B, my password is
Can I have an IP?
Domain Controller
User authenticationhi, Im 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

• Dont 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 DCs public key

20
Finding the DC

• Switches construct spanning tree Rooted at DC
• Switches dont advertisepath to DC until
  theyveauthenticated
• 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
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
?
DC

• 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

ltsrc,dst,sprt,dprtgt
ltARP replygt
ltARP,bobgt
ltsrc,dst,sprt,dprtgt
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?