Extending Secure Research Networks into the Science DMZ
Time 10/06/15 12:30PM-01:45PM
Room Room 12
Arizona State University (ASU) is a major, public, metropolitan research university with one of the largest student populations in the country, supported by world-class faculty. The ASU mission is to create a “New American University” by delivering teaching and conducting research that crosses disciplinary boundaries, in multiple ways, with a goal to create what might be described as “intellectual fusion”. Through its New American University model, ASU is applying the trans-disciplinary approach to complex problems at scale.
University senior leadership envisions research centers without walls that are collaboration-centric, with open, Big Data frameworks that support global collaboration; dedicated bandwidth, free of policy or capacity restrictions to support research of public value. Connected to a “friction-free” science DMZ; inter/intra-university high-speed 10G/40G/100G interconnects via the Internet2 Innovation Platform; programmable, pluggable architectures for the next generation of research computing ; OpenFlow based software-defined networking for efficient and effective low-touch network management free from legacy hardware bottlenecks; RaaS workload based provisioning for holistically defined scientific challenges are the pillars supporting the vision.
We bring to the conversation a novel synergism integrating Big Data platforms and supercomputing technologies with new approaches to service provisioning. ASU as a Shepard in this emerging approach to research computing understands this approach is not without risk and thoughtful risk mitigation that serves to support the primary directives of extending research computing to all Arizonans and improving the 'time to research'.
Integration of the ScienceDMZ model, Network Function Virtualization and Software-Defined Networking serve to enable various network applications to run on the controller to manage the network directly by configuring packet-handling mechanisms in underlying devices.
We believe the path in OpenFlow adoption for all networks, it is virtually inevitable that legacy security appliances, such
as firewalls, have to be migrated to OpenFlow-based networks by re-designing and implementing them as compatible security
applications. However, our experience reveals that OpenFlow not only presents tremendous opportunities to networking, but also brings
great challenges for building a secure research computing infrastructure. In this session we will demonstrate the ASU approach to resolve the following challenges:
1.) What a ScienceDMZ is and what the ScienceDMZ is not.
2.) Inspecting Dynamic Network Policy Updates in OpenFlow:
In an OpenFlow network, network states are dynamically updated and
configurations are frequently changed. Thus, simply checking flow packet violation by monitoring packet-in behaviors in
a firewall application is not effective, since flow policy violation, which indicates exiting flow policies violate the firewall
policy induced by the changes of network states and configurations such as updating flow entries and firewall rules, should
be detected and resolved in real time as well.
3.) Checking Indirect Security Violations: OpenFlow allows various Set-Field actions that can dynamically change the
packet headers. Adversaries could take advantage of this feature to strategically enable flow rules that would evade security
mechanisms (e.g. firewalls). In addition, flow rules may overlap each other in a flow table, indicating intra-table dependency
of flow rules. The rules in a firewall policy may also overlap each other. These rule dependencies could also be
leveraged by malicious OpenFlow applications to bypass firewalls.
4.) Architecture Option: A centralized SDN firewall can immediately enforce updated rules in the firewall policy to check
security violations. However, when a flow policy violation is detected, it can only reject the new flow policy or flush resident
flow policy that causes the violation. If only partial packets matching a flow policy violate the firewall policy, eliminating
the flow policy may drop legal traffic. A distributed SDN firewall may directly resolve flow policy violations by propagating
and enforcing the firewall policy at each individual entry (ingress switch) of the flow in the network. However, a distributed
firewall needs a complicated revocation and re-propagation mechanism to handle dynamic policy updates.
5.) Stateful Monitoring: Currently, OpenFlow only provides very limited access to packet-level information in the controller.
In addition, the OpenFlow forwarding plane is almost stateless and unable to actively monitor flow status without the involvement
of the controller. Therefore, it is challenging to fully support stateful packet inspection in SDN firewalls.
6.) Extending the Research network to the desktop or research lab around campus: We address the tools, options and policy required to securely offer a service that serves research free from the latency introduced by legacy solutions.
7.) Now that we are connected, what can we do?
We believe this approach will empower our research community to consume research computing as needed thus facilitating the next major wave of innovation, in a manner consistent with university compliance.
Please get your lunch from the buffet located closest to the meeting room.
Speaker Jay Etchings Arizona State University
Primary track Security
Secondary tracks Research