SANE: A Protection Architecture for Enterprise Networks Authors: Martin Casado, Tal Garfinkel, Aditya Akella, Michael J. Freedman Dan Boneh, Nick McKeown, Scott Shenker Presented by: Michael Haggerty 1Topic # 1

Security Concerns in the Enterprise Current security solutions try to retrofit access control into a permissive network – ACL’s, packet filters and other middleboxes SANE – a single protection layer that governs all connectivity in the enterprise – Uses a centralized solution to grant access to services Topic # 22

Overview What’s wrong with existing technology Security Architecture for the Networked Enterprise (SANE) – Domain Controller – Point to Point Communications – Interoperability – Fault Tolerance – Additional Features – Attack Resistance – Resource Exhaustion Can SANE handle the overhead? Related work My Opinion Conclusion Topic # 33

What’s wrong with existing technology? Complexity of Mechanism Security policy is distributed among VLANs, ACLs, firewalls, NATs, ect. Configuration is complex Based on address and physical ports rather than authenticated end points When a small change occurs it can require complex reconfiguring Common response it to secure at one point (firewall) SANE allows high level policies to be expressed centrally – policies are enforces and configured by a single source! Topic # 44

What’s wrong with existing technology? Proliferation of trust Switches and routers must correctly export link state, calculate routes and perform filtering Overtime these functions have become more complex leading to more vulnerabilities. SANE proposed to replace this with simple, minimally trusted forwarding elements in order to reduce the number of trusted elements to one centrally managed controller. Topic # 45

What’s wrong with existing technology? Proliferation of Information – Topology information is easy to gather in enterprise networks – Switches and routers will routinely broadcast information about topology in plaintext (OSPF) – Ping (traceroute) and ARP scans, port scanning and SNMP – Filtering ICMP and changing SNMP passphrases are common defenses SANE hides the network structure as well as the location of critical services and hosts from unauthorized network entities. Topic # 46

SANE SANE seeks to provide protection robust enough for government, military and financial networks – Robust means protection from insider (authenticated uses and switches) and outsider(unauthorized user plug into the network) threats. SANE works in the enterprise – Enterprise networks are carefully planned and centrally manages – Most hosts are clients connecting to predictable services (mail, file and print, HTTP proxies or ssh gateways). – Most clients are already authenticated via LDAP or Active Directory – Able to quickly adopt new protection architecture Topic # 57

SANE Domain Controller (DC) Central component of the SANE network and is responsible for: – Authenticating users and hosts – Advertising available services – Deciding who can connect to these services – Allows hosts to communicate by handing out capabilities Topic # 58

SANE The DC performs 3 main functions: Authentication Service – – Authenticates principles and switches – Maintains symmetric keys with each for secure communication Network Service Directory (NSD) – Replacement for DNS (each service has a unique name) – Maintains an Access Control List (ACL) for each service – When a principal wants to access a service it looks it up in the NSD and returns a capability if it is allowed to access it. Topic # 59

SANE The DC provides 3 main functions (continued) Protection Layer Controller – Responsible for generating, maintaining and revoking capabilities – A capability is a switch-level source route from the client to a server – Encrypted in layers to prove they originated from DC and to hide topology – Keeps a complete view of the topology – Adapt the network when things go wrong Topic # 510

Provide Isolation Layer Physical Datalink Network Transport Application Introduce layer 2.5 Isolation Layer EthernetSANEIP.. Strictly defines connectivity Slide borrowed from 11Topic # 5

Packet types in a SANE network HELLO packets are used for immediate neighbor discovery and thus are never forwarded. DC packets are used by end hosts and switches to communicate with the DC; they are forwarded by switches to the DC along a default route. FORWARD packets are used for most host-to-host data transmissions; they include an encrypted source route (capability) which tells switches where to forward the packet. REVOKE packets revoke a capability before its normal expiration; they are forwarded back along a capability’s forward route. Topic # 512

SANE – Communication with the DC SANE builds a minimum spanning tree with the DC as root using HELLO packets No switch learns the entire topology – just their neighbors The spanning tree is only used to establish default routes for forwarding packets to the DC (DC packets) Topic # 513

SANE – Communication with the DC (continued) Switches authenticate with DC and establish symmetric key – IKE2 used for key exchange Keys used to establish confidentiality, integrity and replay defense with the DC via an authentication header – similar to IPsec’s ESP header. Topic # 514

SANE – Communication with the DC (continued) All capability requests and link state requests traverse the MST. As the DC packet traverses the MST a request capability is generated as an encrypted onion packet (containing the previous and next hop) DC uses these requests to communicate back to the sender, to learn about the topology and identify misbehaving senders. Topic # 515

SANE – Point to Point Communications Server publishes service under a unique name to the DC Client communicates with DC to authenticate and obtain capability DC communicates network path to client Client communicates with server via capability communicated from DC Topic # 516

SANE: 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 Slide borrowed from 17Topic # 5

SANE: 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 Slide borrowed from 18Topic # 5

SANE – Revoking Access A DC can revoke a capability A client can report a misbehaving sender for a misused capability How? – Victim sends a revocation request – DC verifies that the requester is on the capabilities path – DC returns a signed packet of type REVOKE – If a switch receives traffic from a revoked capability it will silently drop the traffic Topic # 519

Interoperability with non SANE network components Translation proxies – translate between IP naming events and SANE events. (ie map DNS requests to DC service lookups) Gateways – provide service similar to a NATs. Position on the perimeter to allow for connectivity to the wide area. Broadcast – link layer broadcasts are forwarded to the DC and the DC will reply Topic # 520

Fault Tolerance – Can a centralized solution be feasible? Replicating the DC The DC is logically centralized – this does not mean it has to be physically centralized! Have a MST rooted to each DC Distributed Load Recovering from network failure It is the end hosts responsibility to detect network failure. Switches to end host communication is not allowed and would allow for more DoS attack paths End host will communicate failure to DC which will issue new capabilities to end host Topic # 521

Additional Features Middleboxes and Proxies – Traditionally proxies are placed at choke points. In a SANE network proxies can be placed anywhere and the DC can insure that traffic passes through them Mobility – When a client changes access points it can request a new capability and REVOKE its old one. Anti-Mobility – SANE can prevent hosts and switches from moving by disallowing access if they do Centralized logging – The DC is an ideal place for network wide communications logging. Topic # 522

Attack Resistance Access Control Lists (ACLs) The NSD uses ACLs for directories, preventing attackers from enumerating services. This will prevent an attacker from discovering a particular application which may have a known vulnerability. Encrypted Source Routes and Link-State Updates Prevent attackers from learning the topology or enumerating services Authenticated Network Components Authenticated switches cannot lie about their connectivity or create arbitrary links. Spanning tree and routing attacks are thwarted due to the DCs centralized control Topic # 523

Resource Exhaustion Flooding – Flooding attacks are handled through revocation. Rate-limits for capabilities requests – DC tell neighbors to disconnect it if limits are violated Revocation State Exhaustion – SANE switches must keep a list of revoked capabilities. An attacker might try to fill the list up by dumping a huge list of revoked capabilities at one. – If revocation lists fills – the switch dumps and reloads – DC tracks number of revocations per sender – sender can be removed from ACLs if sends to many REVOKEs Topic # 524

Handling Malicious Switches Switches have minimal functionality in SANE – but could potentially sabotage by: Falsely advertising a smaller distance during MST build, which would cause additional DC traffic to flow through it. – Start dropping packets – degrading service Attract traffic by falsifying link-state updates – colluding nodes can attract traffic without detection – SANE avoids this by requiring switches to authenticate Topic # 525

Handling Malicious DCs DCs are highly trusted entities in SANE – a compromise of the DC can hand total control to an attacker This can be avoided by replication of the DC and distributing the trust among several DCs Spread cryptographic responsibility so that 2 or more DCs are required to issue a capability – An attacker gains no advantage by taking only 1 DC – DC synchronization is an issue – SANE uses standard Byzantine agreement protocols Topic # 526

Taking SANE for a Test Drive Interconnected hosts on a 100Mbps Ethernet Had to change MTU size to 1300 bytes on hosts to provide room for SANE headers. (only change) DCs preloaded with public keys of the switches Capabilities use 8b, switch IDs 32b, service IDs 16b, innermost layer uses 24B and each additional layer uses 14B – 10 switch limit – need 164B for SANE header Topic # 627

Taking SANE for a Test Drive Client looking for HTTP would be directed to the DC for authentication (until user authenticates all request to DNS are routed to the DC via a translation proxy) Once user is authenticated the translation proxy would handle requests and grant capabilities to the end user Topic # 628

Evaluation Goal: to show that SANE can fit into an enterprise network and can handle the workload DC was able to issue 40,000 capabilities at worst over 10 hops Switches were able to saturate 100Mbps networks up to 10 hops Data collected from Lawrence Berkley National Lab for 34 hours in Jan million packets collected – 20,849 DNS request and 145,577 TCP connections Topic # 629

Evaluation The DNS and TCP request rates provide an estimate for DC requests by end hosts in a SANE network – the peak rate was < 200/sec 200 times lower than what unoptimized worst case DC could handle using a 10 hop network Concurrent TCP connection peaked at 1111 – median was 27. At worst case the DC can handle 40 time more request during a network link failure. Packet carrying the forward and return capabilities would be at most 0.4KB in size – adding a maximum of 0.646Mbps of control traffic Topic # 730

Results Only a few DCs would be needed on a network with tens of thousands of hosts DC replication is probably more relevant to ensure uninterrupted service in the event of DC failure. Topic # 731

Related Work Network Protection Mechanisms – Firewalls – protection of network perimeters – Distributed Firewalls are similar to SANE Dealing with Router Complexity – Routers can make firewalls irrelevant by routing around them – 4D Architecture (Rexford) routing should be separate from forwarding and policies should be centralized Topic # 832

Related Work Expanding the Link Layer – Replacement of MST based forwarding with a link- state forwarding – Using a Directory Service instead of ARP Capabilities for DDoS Prevention – Using network enforced capabilities on the WAN – Unlike SANE capabilities are built on-route (no central control) Topic # 833

My Opinion Proposed solution is lacking No comparison to Directory based Network Operation Systems (NOS) currently available – Microsoft Active Directory – Novell Directory Services Does not adequately show how SANE is better than existing models Experiments show that SANE can fit into a network but do not show that it makes a network more secure! Topic # 934

Conclusion SANE adds a layer to the network stack Centralized control via Domain Controllers that use cryptography to authenticate all switches, users and servers. ACLs used to issue capabilities and routing paths Onion Layering hides Network Topology Topic # 1035

Questions? Topic #36