Transcript Document

SANE: Addressing the Protection
Problem in Enterprise Networks
Martin Casado
Tal Garfinkel
Michael Freedman
Aditya Akaella
Dan Boneh
Nick McKeown
Scott Shenker
Usenix Security ‘06
August, 2006
Usenix Security 2006
SANE
SANE: a proposal for a NAC
(network access control) architecture
– Enterprise networks only
– “Default off” design
– Centralized policy management,
distributed policy enforcement.
August, 2006
Usenix Security 2006
SANE
(Secure Architecture for the Networked Enterprise)
 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
August, 2006
Usenix Security 2006
Provide Isolation Layer
Ethernet SANE
IP ..
Transport
Network
Datalink
Physical
Introduce layer 2.5
Isolation Layer
Strictly defines connectivity
August, 2006
Application
Usenix Security 2006
Action Sequence!
martin.friends.ambient-streams
Authenticate
Publish
Request
hi, I’m tal, my password is
martin.friends.ambient-streams
Authenticate
martin.friends.ambient-streams
1 4 3 4
4
Ambient streams
allow
sundar,
hi, I’mtal,
martin,
myaditya
password is
4 13 4 4
3 1 2 2 Ambient streams 4 4
Ambient streams
Client port
1 31 1 22
2 Client port 1 3 1 2 2
Client port
1
4
4
2
3
3
4 1
3 4 4
4
Ambient streams
1 3 1 2
2
August, 2006
Ambient streams
1 3 1 2
2
Client port
Usenix Security 2006
Client port
Ambient streams
1 3 1 2
2
Client port
Overview
•Send link state information to
the DC
•Publish services at the•Provide
DC
default connectivity to
•Specify access controls
the DC
(export streams.ambient
allow tal)
Domain Controller •Validate capabilities
•Request access to services
•Forward packets base on
•Use appropriate capability
for each packet
capability
•Authenticates
switches/end•Enforce revocations
hosts
•Established secret with each
switch
Switches
•Contains network topology
•Hosts services (by name)
•Manages permission checking
•Creates and issues capabilities
End-Hosts
August, 2006
Usenix Security 2006
Bootstrapping
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
August, 2006
Usenix Security 2006
Are you INSANE?
 Fault Tolerance
– Central control!
– Loss of adaptive routing!
 Revocation
August, 2006
Usenix Security 2006
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
Complexity is a result of “stateless” DC
August, 2006
Usenix Security 2006
Implementation
Prototype system built in software
(currently working on the hardware)
Ran in 9 workstation network for a month
August, 2006
Usenix Security 2006
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
1
2
3
SW2
2
1 SW1
4
Esw1
– path information
– Expiration
– Unique ID
MAC
1,4
MAC
3,2
MAC
2,1
MACService
Esw2
August, 2006
Usenix Security 2006
port
CAP-ID Expiration
User Authentication
 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)
August, 2006
Usenix Security 2006
Kerberos
DC
Actually ….
Routing and permission
check can be decoupled
Network functionality provided
by DE’s
Permission check at DC,
informs DE to set up route
with 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 )
August, 2006
Usenix Security 2006
Scalability
DCs can be physically replicated
Test - 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
August, 2006
Usenix Security 2006