1 / 17

Author: Martin Casado , Tal Garfinkel , Aditya Akella , Michael J. Freedman

SANE: A Protection Architecture for Enterprise Networks. Author: Martin Casado , Tal Garfinkel , Aditya Akella , Michael J. Freedman Dan Boneh , Nick McKeown , Scott Shenker Publisher: IEEE COMMUNICATIONS SURVEYS & TUTORIALS Presenter: Ching Hsuan Shih

jens
Télécharger la présentation

Author: Martin Casado , Tal Garfinkel , Aditya Akella , Michael J. Freedman

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SANE: A Protection Architecture for Enterprise Networks Author: Martin Casado, Tal Garfinkel, Aditya Akella, Michael J. Freedman Dan Boneh, Nick McKeown, Scott Shenker Publisher: IEEE COMMUNICATIONS SURVEYS & TUTORIALS Presenter: ChingHsuan Shih Date: 2013/10/09

  2. Outline 1. Instroduction 2. What’s Wrong with Existing Technuques? 3. System Architecture 4. Attack Resistance 5. Implementation 6. Evaluation 7. Related Work 8. Conclusion

  3. 1. Instroduction • Allow natural policies that are simple yet powerful. - We seek an architecture that supports natural policies that are independent of the topology and provide least privilege access to resources. • Enforcement should be at the link layer, to prevent lower layers from undermining it. • Hide information about topology and services from those without permission to see them. • Have only one trusted component.

  4. 2. What’s Wrong with Existing Techniques? • Complexity of Mechenism • Proliferation of Trust • Proliferation of Information

  5. 3. System Architecture • This section describes two versions of the SANE architecture: 1. a clean –slate approach, in which every network component is modified to support SANE 2. inter-operate with unmodified end hosts running standard IP stacks

  6. 3.1 Domain Controller (DC) DC is the central component of a SANE network and responsible for authenticating users and hosts. • 1. Authentication Service • 2. Network Service Directory (NSD) • 3. Protection Layer Controller • Revoking Access Figure 2: SANE operates at the same layer as VLAN Figure 1: The SANE Service Model

  7. 3.2 Interoperability • Translation Proxies • Gateways • Broadcast • Service Publication

  8. 3.3 Fault Tolerance • Replicating the Domain Controller • Service directory must maintain consistency among multiple DCs • Recovering from Network Failure • Send periodic probes or keep-alive messages to detect failures and request fresh capabilities

  9. 4. Attack Resistance • Access-control lists • The NSD uses ACLs for directories, preventing attackers from enumerating all services in the system • Encrypted, authenticated source-routes and link-state updates • These prevent an attacker from learning the topology or from enumerating hosts and performing port scans • Authenticated network components • The authentication mechanism prevents unautherticated switches from joining a SANE network, thwarting a variety of topology attacks

  10. 4.1 Resource Exhaustion • Flooding • Rate-limit requests for capabilities to the DC • Revocation state exhaustion • Generate a new key to the DC • DC tracks the number of revocations issued per sender

  11. 4.2 Tolerating Malicious Switches • Sabotaging MST Discovery • Bad Link-State Advertisement Figure 5: Attacker C can deny service to A by selectively dropping A’s packets, yet letting the packets of its parent (B) through. As a result, A cannot communicate with the DC, even though a alternate path exists through D.

  12. 4.3 Tolerating a Malicious DC • Split the DCs’ secret key across a few servers, such that two of them are needed to generate a capability.

  13. 5. Implementation All development was done in C++ using the Virtual Network System (VNS) within the group LAN -Seven physical hosts on 100 Mb Ethernet for one month The implementation consists of a DC, switches and IP proxies - No support for multiple DCs - No support for tolerating malicious switches

  14. 5. Implementation (Cont.) • IP Proxies and SANE Switches • The proxies use ARP (Address Resolution Protocol) cache • Support automatic neighbor discovery, MST construction, link-state updates and packet forwarding • Domain Controller • Capability construction • Service Directory

  15. 6. Evalution Table 1: Performance of a DC and switches Figure 6: DNS requests, TCP connection establishment requests, and maximum concurrent TCP connections per second, respectively, for the Lawrence Berkeley National Laboratory enterprise network.

  16. 7. Related Work • Network Protection Mechanisms • Dealing with Routing Complexity • Expanding the Link-layer • Capabilities for DDOS prevention

  17. 8. Conclusion • We believe that enterprise networks are different from the Internet at large and deserve special attention: • Security is paramount • Centralized control is the norm • Uniform and consistent policies are important

More Related