Ethane addressing the protection problem in enterprise networks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

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


  • 74 Views
  • Uploaded on
  • Presentation posted in: General

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]

Download Presentation

Ethane: Addressing the Protection Problem in Enterprise Networks

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


Ethane addressing the protection problem in enterprise networks

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?


Ethane addressing the protection problem in enterprise networks

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 dc

Initial Traffic to DC

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


Ethane addressing the protection problem in enterprise networks

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


Questions

Questions?


  • Login