SANE: A Protection Architecture for Enterprise Networks

1. 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

2. 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

3. 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!

4. 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

5. 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 Application Transport Network Datalink Physical

6. 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!!

7. 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

8. Our Approach: SANE(Security Architecture for the Networked Enterprise) Take an extreme point in design space… • Default on  Default off • Decentralized trust  centralized • No network enforcement  enforced per hop • Meaningless IPs  Tightly bound end-points • Transparent information  restricted

9. When Does this make sense? • Security is paramount • Practical deployment strategy • Fork-lift upgrades • New networks created often • Centralized administration • Notion of principles (e.g. users) • Structured communication

10. Ethernet SANE IP .. Provide Isolation Layer Application • Strictly defines connectivity Transport Introduce layer 2.5Isolation Layer Network Datalink Physical

11. Ambient streams 1 1 1 1 3 3 3 3 1 1 1 1 1 4 4 1 1 2 2 2 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4 4 4 4 4 Client port Client port Client port Client port 1 1 2 2 Ambient streams Ambient streams Ambient streams Ambient streams Ambient streams 2 2 Client port Client port SANE:Action Sequence! Authenticatehi, I’m tal, my password is Publishmartin.friends.ambient-streamsallow tal, sundar, aditya martin.friends.ambient-streams Requestmartin.friends.ambient-streams Authenticatehi, I’m martin, my password is 1 2 1 4 4 2 3 3 4 1

12. Send link state information to the DC • Provide default connectivity to the DC • Validate capabilities • Forward packets base on capability • Enforce revocations SANE:Overview • 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

13. Security Properties (Saltzer and Schroeder) • 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

14. SANE Details • How is connectivity to the DC provided? • How are keys established? • How does the DC get the topology?

15. Connectivity to the DC • Switches construct spanning tree Rooted at DC • Switches don’t learn topology(just neighbors) • Provides basic datagram service to DC

16. Ksw4 Ksw1 Ksw3 Ksw2 Ksw1 Ksw2 Ksw3 Ksw4 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)

17. payload payload payload Return Capabilities • Added to all packets to DC • Each switch adds a “layer” • Look the same as DC issuedcapabilities • Used by the DC to determine the • Exact location of the sender

18. Ksw4 Ksw1 Ksw3 Ksw2 Ksw1 Ksw2 Ksw3 Ksw4 Establishing Topology • Switches generate neighbor listsduring MST algorithm • Send encrypted neighbor-listto DC • DC aggregates to full topology • No switch knows full topology

19. 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)

20. Additional Considerations • Fault Tolerance“You’re not SANE you’re INSANE” • Central control! • Loss of adaptive routing! • Attack resistance • Data integrity • Revocation • Wide area issues

21. 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)

22. 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)

23. Attack ResistanceCapabilities • 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 MAC 1,4 CAP-ID Expiration MAC 3,2 MAC 2,1 MAC Service port Esw2

24. 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)

25. payload 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

26. 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)

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

28. 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)

29. Questions?