August, 2006 Usenix Security 2006 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: 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  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 LAN Policy Today

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 Physical Datalink Network Transport Application Introduce layer 2.5 Isolation Layer EthernetSANEIP..  Strictly defines connectivity

August, 2006 Usenix Security 2006 Action Sequence! Publish martin.friends.ambient-streams allow tal, sundar, aditya Authenticate hi, I’m martin, my password is Authenticate hi, I’m tal, my password is martin.friends.ambient-streams Request martin.friends.ambient-streams Ambient streams Client port Ambient streams Client port Ambient streams Client port Ambient streams Client port 4 4 Ambient streams Client port 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  Switches construct spanning tree Rooted at DC –Only advertise new path after successfully authenticating  Provides basic datagram service to DC (switches build capabilities as packets are forwarded to the DC)  Switches don’t learn topology (just neighbors) Connectivity to the DC

August, 2006 Usenix Security 2006 Establishing Shared Keys  Switches authenticate with DC and establish symmetric key  Ike2 for key establishment  All subsequent packets to DC protected by esp header K sw1 K sw2 K sw3 K sw4 K sw1 K sw3 K sw4 K sw2

August, 2006 Usenix Security 2006 Establishing Topology  Switches generate neighbor lists during MST algorithm  Send encrypted neighbor-list to DC  DC aggregates full topology –Can verify false advertisements –Can verify if duplicate or non-registered switches on network  No switch knows full topology K sw1 K sw2 K sw3 K sw4 K sw1 K sw3 K sw4 K sw2

August, 2006 Usenix Security 2006  Fault Tolerance –Central control! –Loss of adaptive routing!  Revocation Are you INSANE?

August, 2006 Usenix Security 2006  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) Adaptive Routing

August, 2006 Usenix Security 2006  Exists today, sort of.. (DNS)  Permission check is fast  Replicate DC –Computationally (multiple servers) –Topologically (multiple servers in multiple places) Permission Check per Flow?

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  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 ,4 3,2 4 2,1 Service port MAC E sw1 E sw2 SW1 SW2 CAP-IDExpiration 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 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 ) Actually ….

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