4. DADC Scalability
To evaluate scalability of DADC, we measured its performance against large network specifications. The network is a fault-tolerant VPN connecting multiple sites as described in 16. Each site contains a gateway router that is connected to a WAN router. All gateway routers are linked in a ring of GRE/IPSec tunnels with OSPF running over them. All WAN routers are also connected in a ring with RIP running over them. Thus, if there are N sites then there are 2*N routers in the specification. We installed DADC on an Ubuntu 14.01 server consisting of two Intel Xeon E5-2697 2.70GHz processors, 54 GB RAM, and a 100 GB SSD Hard Drive. We scaled the number of routers from 20 to 20,000 in increments of 100 and measured the synthesis time, i.e., the time to generate the solution and the Cisco configuration files for all routers. Figure 7. Measuring DADC scalability for a fault-tolerant VPN shows our results. The time to generate a 1,000 router solution was only 10 seconds, while a 10,000 router solution took 76 minutes. Our largest test case of a 20,000 router specification required almost 25 hours.
The synthesis time does eventually scale non-linearly with the number of routers, perhaps because SAT is NPcomplete. However, the results are deemed favorable given that there is a very large number of enterprise networks with a few thousand routers. These networks can be efficiently synthesized and managed with DADC in minutes. The time taken for larger networks is still orders of magnitude smaller than with manual practice.
5. DADC Applications
DADC is being transitioned to real enterprises for network planning and cyber defense exercises. In current practice of network planning, one draws network requirement diagrams such as Figure 2, then translates those into abstract configurations, then translates those into vendor-specific configurations, then creates a physical network and applies these configurations to the components. If the network does not work as expected, the error can be at any of the above stages. Thus, it can take a very long time to resolve and fix it. With DADC, one can specify the requirements in its highlevel text or visual language and then automatically generate a working network under emulation in under a minute. If the network does not work, it is definitely a problem with the requirements. The translation of requirements into abstract and vendor-specific configurations and the application of these to emulated components are guaranteed to be correct. Thus, network planning becomes far more efficient than with current practice.
In cyber defense exercises, blue teams defend against attacks by red teams. One use of DADC is to evaluate the effectiveness of blue team defensive actions. For example, the blue team may cut off an attacker’s access by placing such a stringent access-control list on a router that even legitimate users are blocked. Such blockage may not be obvious as legitimate users are simulated by computers who may not complain when their traffic is disrupted. DADC’s diagnosis, visualization and path planning algorithms can be used to check if legitimate services have been disrupted. DADC could, of course, be used to build the cyber defense exercise networks of realistic scale and complexity. Finally, emulation could be used to conduct the entire exercise in a virtualized environment to make it much more efficient for users to try out new attack and defense maneuvers.