1. Resonance: Dynamic Access Control in Enterprise Networks Ankur Nayak, Alex Reimers, Nick Feamster, Russ Clark School of Computer Science Georgia Institute of Technology

2. Summary Enterprise and campus networks are dynamic –Hosts continually coming and leaving –Hosts may become infected Today, access control is static, and poorly integrated with the network layer itself Resonance: Dynamic access control –Track state of each host on the network –Update forwarding state of switches per host as these states change

3. State of the Art Todays networks have many components bolted on after the fact –Firewalls, VLANs, Web authentication portal, vunerability scanner Separate (and perhaps competing) devices for performing the following functions –Registration (based on MAC addresses) –Scanning –Filtering and rate limiting traffic

4. Authentication at GT: START

5. Problems with Current Architecture Access Control is too coarse-grained Cannot dynamically remap hosts to different portions of the network –Needs a DHCP request which for a windows user would mean a reboot Monitoring is not continuous Idea: Express access control to incorporate network dynamics.

6. Problems with Current Approaches Existing enterprise security techniques are reactive and ad-hoc A mix of security middleboxes, intrusion detection systems etc. result in collection of complex network configurations Possible negative side effects –Misconfiguration –Security problems

7. Resonance: Summary Step 1: Associate each host with generic states and security classes. Step 2: Specify a state machine for moving machines from one state to the other. Step 3: Control forwarding state in switches based on the current state of each machine. –Actions from other network elements, and distributed inference, can affect network state.

8. Applying Resonance to START

9. Resonance: Step-by-Step

10. Preliminary Implementation: OpenFlow OpenFlow: Flow-based control over the forwarding behavior of switches and routers –A switch, a centralized controller and end-hosts –Switches communicate with the controller through an open protocol over a secure channel Why OpenFlow? –Dynamically change security policies –Central control enables Specifying a single, centralized security policy Coordinating the mechanisms for switches

12. Resonance Controller: NOX NOX: Programmatic interface to the OpenFlow controller –Ability to add, remove and reuse components We are building the Resonance controller using NOX

13. Research Testbed

14. Challenges Scale –How many forwarding entries per switch? –How much traffic at the controller? Performance Responsiveness Security –MAC address spoofing –Securing the controller (and control framework)

15. Summary Resonance: An architecture to secure and maintain enterprise networks. –Preliminary design –Application to Georgia Tech campus network –Planned evaluation Many challenges remain –Scaling –Performance Questions?