sane: a protection architecture for enterprise networks

2005 Stanford and ICSI

Martin Casado (Stanford)

Tal Garfinkel (Stanford)

Aditya Akella

(CMU/Stanford)

Dan Boneh (Stanford)

Nick McKeown (Stanford)

Scott Shenker (ICSI/Berkeley)

SANE: A Protection Architecture for Enterprise Networks


Enterprise Security is Important

$8.7 billion information security industry (US alone)

Intellectual Property Protection(Valve code leak)

Downtimes are costly(Disney)

User-information leaks are bad(California bill number: SB 1386)

Regulatory Compliance HIPAA Sarbanes Oxley


A Quick Look at IP

Default on: everyone can talk to everyone

Trusted end-hosts, “stupid network” Decentralized (trust)

Loosely bound end-points

No hiding of information Communicating end points topology

Worms are a testimony to the success of IP!


IP and Security

Default ON overly permissive (“every psychopath is your next-door neighbor” – Geer)

trusted end-points powerful users/attackers

Stupid network no defense in depth Proliferation of TCB 1 router is enough weak end-points useless for

discrimination No hiding of info reconnaissance is easy


Retrofitting Security onto IP

Designed for Security Firewalls, Router ACLS Port Security IDS/NDS/IPS

(scan detection, anomaly detection, signature detection)

VLANs

Pushed Into Service Ethernet Switches NATs, Proxies Physical

Datalink

Network

Transport

Application


Policies and Protection in Enterprises

Connectivity is difficult to reason about

Network config = sum of router and end-host configs

Hard to express meaningful policies

Enterprise networks are brittle Difficult to deploy new protocols, define

new policies Easy to break existing policies

Yet, existing mechanisms don’t provide adequate security!!


Short Recap

IP networks Default on No support in network Decentralized trust Loosely bound end-points Proliferation of information

Exisiting enterprise security technologies Many Complex Can’t declare policy simply


Our Approach: SANE(Security Architecture for the Networked Enterprise)

Take an extreme point in design space…

Default on Default offDecentralized trust centralizedNo network enforcement enforced per

hopMeaningless IPs Tightly bound end-

pointsTransparent information restricted


When Does this make sense?

Security is paramountPractical deployment strategy

Fork-lift upgradesNew networks created often

Centralized administrationNotion of principles (e.g. users)Structured communication


Provide Isolation Layer

PhysicalDatalinkNetwork

Transport

Application

Introduce layer 2.5Isolation Layer

Ethernet SANE IP ..

Strictly defines connectivity


SANE:

Action Sequence!Publishmartin.friends.ambient-streamsallow tal, sundar, adityaAuthenticatehi, I’m martin, my password is

Authenticatehi, I’m tal, my password is

martin.friends.ambient-streamsRequest

martin.friends.ambient-streams

1

4

34

4 13

1

2

2

Ambient streams

1 3 1 2 2 Client port

1 4 3 4 4 Ambient streams

1 3 1 2 2 Client port4 3 4 4 Ambient streams


3 4 4 Ambient streams


4 4 Ambient streams



4 Ambient streams


SANE:

OverviewDomain Controller

Switches

End-Hosts

•Authenticates switches/end-hosts•Established secret with each switch•Contains network topology•Hosts services (by name)•Manages permission checking•Creates and issues capabilities

•Send link state information to the DC•Provide default connectivity to the DC•Validate capabilities•Forward packets base on capability•Enforce revocations

•Publish services at the DC•Specify access controls(export streams.ambient allow tal)•Request access to services•Use appropriate capability for each packet


Default off (capabilities provide all connectivity)(failsafe defaults, least privilege)

Single, simple mechanism (economy of mechanism)

Capability checked at every step(complete mediation)

Capabilities bind end-hosts to location High level policy declaration

Fine-grained policies(psychological acceptability)

Don’t reveal (sender, packet path, topology)(least knowledge)

Immutable transport address allows fine grained access controls

Security Properties (Saltzer and Schroeder)


How is connectivity to the DC provided? How are keys established? How does the DC get the topology?

SANE Details


Connectivity to the DC

Switches construct spanning tree Rooted at DC Switches don’t learn topology

(just neighbors) Provides basic datagram service to DC


Establishing Shared Keys

Switches authenticate with DCand establish symmetric key

Ike2 for key establishment All subsequent packets to DC

have “authentication header”(similar to ipsec esp header)

Ksw1

Ksw2

Ksw3

Ksw4

Ksw1

Ksw3Ksw4

Ksw2


Return Capabilities

Added to all packets to DC Each switch adds a “layer” Look the same as DC issued

capabilities Used by the DC to determine the Exact location of the sender

payload

payload

payload


Establishing Topology

Switches generate neighbor listsduring MST algorithm

Send encrypted neighbor-listto DC

DC aggregates to full topology No switch knows full topology

Ksw1

Ksw2

Ksw3

Ksw4

Ksw1

Ksw3Ksw4

Ksw2


Summary of mechanism

Default connectivity to DC (via MST) All principles authenticate (switches,

users) Users publish/request services from DC DC returns encrypted source route

Provides all host-to-host connectivity Opaque Non-composable Include transport address (fine-grained)


Fault Tolerance“You’re not SANE you’re INSANE” Central control! Loss of adaptive routing!

Attack resistance Data integrity Revocation

Wide area issues

Additional Considerations


Fault Tolerance:

Adaptive Routing On failure, end-hosts must refresh

capabilities Timeouts to detect failures

Can result in “request storm” at DC Issue multiple capabilities

(hand out n of the k shortest paths)

More switch level redundancy(doesn’t undermine security!)

Path load balancing(randomly choose one of the k shortest paths)


Fault Tolerance: DC: Single Point of Failure?

Exists today (DNS) Capability generation is fast

(crummy implementation = 20k – 40k per second)

Replicate DC Computationally (multiple servers) Topologically (multiple servers in multiple

places)


Attack Resistance

Capabilities Onion-encrypted source routes Encryption means, encrypt + MAC Each “layer” using a secret key

shared by the DC and the switch 10 hops = 164 byte header Contain

path information Expiration Unique ID

1 3

1

22

1,4 3,2

4

2,1 Service portMAC MAC MAC MAC

Esw1

Esw2

SW1

SW2

CAP-ID Expiration


Attack Resistance:

And More Security! Intermediary data integrity checks Hiding switch IDs in authentication header Handling growth of trusted computing base

usingthreshold crypto(n of k DCs must be compromised to generate capabilities)


Attack Resistance: Revocation

Request from DC sent back along incoming path Switches maintain small CAMs If CAMs fill, switches generate new keys too many revocations = loose privileges

payload


Wide Area Issues IP Is used for

Wide area routing Common framing (compatibility between end

hosts) In Enterprise Doesn’t provide

Identification Location Local connectivity

Internet connectivity provided by gateway (similar to NAT)


Implementation All components implemented in software Integrated with 9 workstations Managed our group’s traffic for a couple of

weeks


Future Work Research connectivity in the enterprise Real implementation with hardware

switches Extend to multiple domain case Plug into existing directory services (AD,

LDAP) Use DC as a KDC (a la kerberos)


Questions?

sane: a protection architecture for enterprise networks

Documents