August, 2006 Usenix Security 2006

SANE: Addressing the Protection Problem in Enterprise Networks

Martin CasadoTal GarfinkelMichael FreedmanAditya AkaellaDan BonehNick McKeownScott Shenker

Usenix Security ‘06

August, 2006 Usenix Security 2006

SANE: a proposal for a NAC (network access control) architecture

– Enterprise networks only

– “Default off” design

– Centralized policy management, distributed policy enforcement.

SANE

August, 2006 Usenix Security 2006

Properties:– Policy declared centrally over high-level principles

– All network entities (hosts, switches, users) are authenticated

– Permissions checked per flow at central authority

– Access granted in the form of routes(capability = encrypted source route)

– Doesn’t reveal sender, packet path, topology

SANE(Secure Architecture for the Networked Enterprise)

August, 2006 Usenix Security 2006

Provide Isolation Layer

PhysicalDatalinkNetwork

Transport

Application

Introduce layer 2.5Isolation Layer

Ethernet SANE IP ..

Strictly defines connectivity

August, 2006 Usenix Security 2006

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

1 3 1 2 2 Client port

3 4 4 Ambient streams

1 3 1 2 2 Client port

4 4 Ambient streams

1 3 1 2 2 Client port

1 3 1 2 2 Client port

4 Ambient streams

August, 2006 Usenix Security 2006

Overview

Domain 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

August, 2006 Usenix Security 2006

How is connectivity to the DC provided?– Initial MST construction

How are keys established?– Ike2 establishes symmetric key with DC

How does the DC get the topology?– DC aggregates topology after MST creation

Bootstrapping

August, 2006 Usenix Security 2006

Fault Tolerance– Central control!– Loss of adaptive routing!

Revocation

Are you INSANE?

August, 2006 Usenix Security 2006

RevocationRequest from DCSent back along incoming pathSwitches maintain small CAMs If CAMs fill, switches generate new keysToo many revocations = loose

privileges

Complexity is a result of “stateless” DC

payload

August, 2006 Usenix Security 2006

Prototype system built in software(currently working on the hardware)

Ran in 9 workstation network for a month

Implementation

August, 2006 Usenix Security 2006

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

Capabilities

August, 2006 Usenix Security 2006

DC creates route from itself to authentication server

Use third-party mechanism for user authentication– (e.g. radius)

DC places itself on-route for all authentication Snoops protocol to determine if authentication

is successful Identifies user by location + network

identifier (e.g. MAC address)

DC

Kerberos

User Authentication

August, 2006 Usenix Security 2006

Routing and permission check can be decoupled

Network functionality providedby DE’s

Permission check at DC,informs DE to set up routewith optional constraints

DE’s describe in 4D work(Albert Greenberg, Gisli Hjalmtysson, David A. Maltz, Andy Myers, Jennifer Rexford, Geoffrey Xie, Hong Yan, Jibin Zhan, Hui Zhang )

Actually ….

August, 2006 Usenix Security 2006

Scalability

DCs can be physically replicatedTest - 8,000 IP addresses for 34 hours

– 47 million packets, 21,000 DNS requests, 150,000 TCP connections

– Peak: only 200 requests/sec on DC• Test DC can handle 40x this traffic

– Link Failure• Worst case: only 2 requests/sec more

Handful of DCs can handle tens of thousands of end hosts

August, 2006 Usenix Security 2006

Conclusion

Enterprise networks have different needs than the Internet as a whole– Increased security to protect resources– Centralized control

SANE takes an extreme approach to security– Provides minimum possible privileges to end users– Gives attackers fewest possible attack vectors

SANE is still practical– Can be implemented with few modifications to

current networks– Scalable to networks with thousands of nodes