June, 2006 Stanford 2006 Ethane: Addressing the Protection Problem in Enterprise Networks Martin...

June, 2006 Stanford 2006

Ethane: Addressing the Protection Problem in Enterprise

NetworksMartin CasadoMichael FreedmanGlen GibbLew GlendenningDan BonehNick McKeownScott ShenkerGregory Watson

Presented By: Martin CasadoPhD Student in Computer Science, Stanford University

[email protected]://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”


Two Main Challenges

Provide a secure namespace for the policy

Design mechanism to enforce policy


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”


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)


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


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 …


Need “Secure Bindings”

1. Bindings are authenticated

2. Cached bindings are appropriately invalidated

Address reallocation Topology change Permissions changes/Revocation


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


Two Main Challenges

Provide a namespace for the policy

Design Mechanism to Enforce Policy


Policy Language

Declare connectivity constraints overUsers/groupsHosts/NodesAccess pointsProtocolsServices

Connectivity constraints are …Permit/denyRequire middlebox interposition Isolation Physical security


Threat Environment

Suitable for use in .mil, .gov, .com and .edu

Insider attackCompromised machinesTargeted attacks

yet …

Flexible enough for use in open environments


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


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 →


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


How do you bootstrap securely?How is forwarding accomplished?What are the performance

implications?

Many Unanswered Questions


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

•Specify access controls•Request access to services


Finding the DCAuthenticationGenerating topology at DC

Bootstrapping


DC knows all switches and their public keys

All switches know DC’s public key

Assumptions


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


Initial Traffic to DC

2


Initial Traffic to DC

All packets to the DC (except first hop switch) are tunneled

Tunneling includes incoming portDC can shut off malicious packet sources


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


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


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


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


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?


Support multiple deployments with varying policy requirementsfirst deployment by Oct. 31rstRemote deployment by Nov. 15th

Backwards compatible, no modification to end-hosts

1k - 5k requests per secondControl path in softwareData path in hardware (gigabit speeds)

Implementation Goals


Switches implemented on multi-port PCsBootstrapping, flow-setup and software

forwarding completedSwitches currently deployed and supporting

traffic of 16 hosts

Implementation Status


Use simple 2-port switches(bumps)

On links betweenEthernet switches

Prototyping Strategy


Questions?

Date post:	19-Dec-2015
Category:	Documents
View:	216 times
Download:	0 times

June, 2006 Stanford 2006 Ethane: Addressing the Protection Problem in Enterprise Networks Martin...

Documents