SANE: Addressing the Protection Problem in Enterprise Networks

1
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
2
SANE

• SANE a proposal for a NAC (network access
  control) architecture
• Enterprise networks only
• Default off design
• Centralized policy management, distributed
  policy enforcement.

3
LAN Policy Today

• Brittle
• Change a firewall rule, break security policy
• Add a switch, break security policy
• Many heavily trusted components (dhcp, DNS,
  AD/LDAP ..)
• Trade-off between security and diagnostics
  (e.g. ICMP often turned off ..)
• Confusing
• Hard to state meaningful policies

4
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)
• Doesnt reveal sender, packet path, topology

5
Provide Isolation Layer
Application
Transport
Introduce layer 2.5Isolation Layer
Network
Datalink
Physical

• Strictly defines connectivity

6
Action Sequence!
Publishmartin.friends.ambient-streamsallow tal,
sundar, aditya
Authenticatehi, Im tal, my password is
martin.friends.ambient-streams
Requestmartin.friends.ambient-streams
Authenticatehi, Im martin, my password is
1
2
1
4
4
3
3
2
4
1
7
Overview

• 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

Domain Controller

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

Switches
End-Hosts
8
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

9
Connectivity to the DC

• Switches construct spanning tree
• Rooted at DC
• Only advertise new path aftersuccessfully
  authenticating
• Provides basic datagram service to DC(switches
  build capabilities as packets are forwarded to
  the DC)
• Switches dont learn topology(just neighbors)

10
Establishing Shared Keys

• Switches authenticate with DCand establish
  symmetric key
• Ike2 for key establishment
• All subsequent packets to DC protected by esp
  header

11
Establishing Topology

• Switches generate neighbor listsduring MST
  algorithm
• Send encrypted neighbor-listto DC
• DC aggregates full topology
• Can verify false advertisements
• Can verify if duplicate or non-registeredswitches
  on network
• No switch knows full topology

12
Are you INSANE?

• Fault Tolerance
• Central control!
• Loss of adaptive routing!
• Revocation

13
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(doesnt undermine
  security!)
• Path load balancing(randomly choose one of the k
  shortest paths)

14
Permission Check per Flow?

• Exists today, sort of .. (DNS)
• Permission check is fast
• Replicate DC
• Computationally (multiple servers)
• Topologically (multiple servers in multiple
  places)

15
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
• Complexity is a result of stateless DC

16
Implementation

• Prototype system built in software(currently
  working on the hardware)
• Ran in 9 workstation network for a month

17
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

SW2
3
1
2
2
SW1
1
4
Esw1
1,4
MAC
CAP-ID
Expiration
3,2
MAC
2,1
MAC
Service port
MAC
Esw2
18
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 networkidentifier
  (e.g. MAC address)

Kerberos
DC
19
Actually .

• Routing and permission check can be decoupled
• Network functionality providedby DEs
• Permission check at DC,informs DE to set up
  routewith optional constraints
• DEs describe in 4D work(Albert Greenberg, Gisli
  Hjalmtysson, David A. Maltz, Andy Myers,
  Jennifer Rexford, Geoffrey Xie, Hong Yan, Jibin
  Zhan, Hui Zhang )

20
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

21
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