Ethane addressing the protection problem in enterprise networks
Download
1 / 31

Ethane: Addressing the Protection Problem in Enterprise Networks - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Ethane: Addressing the Protection Problem in Enterprise Networks' - aletha


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ethane addressing the protection problem in enterprise networks

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

[email protected]

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”


Two main challenges
Two Main Challenges

  • Provide a secure namespace for the policy

  • Design mechanism to enforce policy


Goal provide secure namespace
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
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
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
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
Need “Secure Bindings”

  • Bindings are authenticated

  • Cached bindings are appropriately invalidated

    • Address reallocation

    • Topology change

    • Permissions changes/Revocation


Why not statically bind
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 challenges1
Two Main Challenges

  • Provide a namespace for the policy

  • Design Mechanism to Enforce Policy


Policy language
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


Threat environment
Threat Environment

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

  • Insider attack

  • Compromised machines

  • Targeted attacksyet …

  • Flexible enough for use in open environments


Our solution ethane
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


Ethane high level operation
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 martin, my password is”

Host authenticatehi, I’m host B, my password is …

Can I have an IP?

Domain Controller

User authenticationhi, I’m 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


Some cool consequences
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


Many unanswered questions
Many Unanswered Questions

  • How do you bootstrap securely?

  • How is forwarding accomplished?

  • What are the performance implications?


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
Bootstrapping

  • Finding the DC

  • Authentication

  • Generating topology at DC


Assumptions
Assumptions

  • DC knows all switches and their public keys

  • All switches know DC’s public key


Finding the dc
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

1

1

2

2

2



Initial traffic to dc1
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


Establishing topology

Ksw4

Ksw1

Ksw3

Ksw2

Ksw1

Ksw2

Ksw3

Ksw4

Establishing Topology

  • Switches generate neighbor listsduring MST algorithm

  • Send encrypted neighbor-listto DC

  • DC aggregates to full topology

  • Note: no switch knows full topology


Forwarding really simple
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


Detailed connection setup
Detailed Connection Setup

?

  • 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

DC

<src,dst,sprt,dprt>

<ARP reply>

<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


Permission check per flow
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)


Implementation goals
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
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
Prototyping Strategy

  • Use simple 2-port switches(bumps)

  • On links betweenEthernet switches



ad