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

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 arent invalidate as DHCP lease times
  come up (or clients leave)
• Security filters arent 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 attacks
  yet
• 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 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
17
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

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

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