View
218
Download
1
Category
Preview:
Citation preview
June, 2006 Stanford 2006
Ethane
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?
June, 2006 Stanford 2006
Enterprise Security
How does this defer in the enterprise setting?Current approach
Difficult to express policiesPolicies are easily broken or circumvented
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”
June, 2006 Stanford 2006
Two Main Challenges
Provide a secure namespace for the policy
Design mechanism to enforce policy
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”
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)
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
June, 2006 Stanford 2006
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 …
June, 2006 Stanford 2006
Need “Secure Bindings”
1. Bindings are authenticated
2. Cached bindings are appropriately invalidated
Address reallocation Topology change Permissions changes/Revocation
June, 2006 Stanford 2006
Why Not Statically Bind?
This is very commonly done!E.g.
Static ARP cache to/from gatewayMAC addresses tied to switch portsStatic IP allocationsStatic rules for VLAN tagging
Results in crummy (inflexible) networks
June, 2006 Stanford 2006
Two Main Challenges
Provide a namespace for the policy
Design Mechanism to Enforce Policy
June, 2006 Stanford 2006
Policy Language
Declare connectivity constraints overUsers/groupsHosts/NodesAccess pointsProtocolsServices
Connectivity constraints are …Permit/denyRequire middlebox interposition Isolation Physical security
June, 2006 Stanford 2006
Threat Environment
Suitable for use in .mil, .gov, .com and .edu
Insider attackCompromised machinesTargeted attacks
yet …
Flexible enough for use in open environments
June, 2006 Stanford 2006
Our Solution: Ethane
Flow-based networkCentral 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
June, 2006 Stanford 2006
Host authenticatehi, 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 authenticationhi, I’m Nick, my password is
?•Permission check•Route computation
Secure Binding StateICQ → 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 →
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
June, 2006 Stanford 2006
How do you bootstrap securely?How is forwarding accomplished?What are the performance
implications?
Many Unanswered Questions
June, 2006 Stanford 2006
Component OverviewDomain 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
June, 2006 Stanford 2006
Finding the DCAuthenticationGenerating topology at DC
Bootstrapping
June, 2006 Stanford 2006
DC knows all switches and their public keys
All switches know DC’s public key
Assumptions
June, 2006 Stanford 2006
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
11
2
2
2
June, 2006 Stanford 2006
Establishing Topology
Switches generate neighbor listsduring MST algorithm
Send encrypted neighbor-listto DC
DC aggregates to full topology
Note: no switch knows full topology
Ksw1
Ksw2
Ksw3
Ksw4
Ksw1
Ksw3Ksw4
Ksw2
June, 2006 Stanford 2006
Establishing Topology
2
June, 2006 Stanford 2006
Each switch maintains flow tableOnly DC can add entry to flow tableFlow lookup is over:
in port, ether proto, src ip, dst ip, src port, dst port
Forwarding = Really simple
out port
June, 2006 Stanford 2006
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 are
forwarded using multi-layerswitching
DC
<src,dst,sprt,dprt>
<ARP,bob>
Alice Bob
<ARP reply>
?<src,dst,sprt,dprt>
Detailed Connection Setup
June, 2006 Stanford 2006
Traffic to DC
All packets to the DC (except first hop switch) are tunneled
Tunneling includes incoming portDC can shut off malicious packet sources
June, 2006 Stanford 2006
Decouple control and data path in switchesSoftware 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
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?
June, 2006 Stanford 2006
Ethane Summary
Current networks insecure and difficult to manageUseless namespaceTopology encoded in config
Ethane addresses issues via architectural changesCentralizedAuthenticated bindings“default off”
June, 2006 Stanford 2006
Questions?
Recommended