Avi: "Radware (NASDAQ: RDWR), is a global leader of application delivery and application security solutions for virtual and cloud data centers. Radware's unique Virtual Application Delivery Infrastructure (VADI) together with its award-winning ADC and Security solutions delivers full resilience for business-critical applications, maximum IT efficiency and business agility. Radware's solutions empower more than 10,000 enterprise and carrier customers worldwide to adapt to market challenges quickly, maintain business continuity and achieve maximum productivity while keeping costs down."
SDNCentral: What is your view on the state of SDN?
Avi: "I think controllers still need to mature and work with applications such as security, ADC, DPI etc. Without applications, there effectively is no use for a controller that will justify changing the networks to become SDN enabled. A couple years ago, many controller proponents talked about an network app store vision. Here we are two years later, and there's still nothing real on that front. Also with OpenDaylight you will need applications. it remains to be seen who's going to provide those."
SDNCentral: What's Radware's general strategy around SDN?
Avi: "Our goals around SDN are to use it to bring the customer more intelligent application delivery and security decisions, simpler implementations, lower solution costs, higher scalability, and easier and abstracted operation.
Radware's SDN strategy transforms the ADC and Security appliances from network service devices to network-wide services. We want to utilize SDN as an enabling architecture to revolutionize the way ADC and security services are implemented and managed. To emphasize and clarify this point, today's traditional networks just forward traffic to the ADC and security devices, by using SDN technologies Radware is turning the network into part of the ADC and Security service itself.
Our SDN Applications for ADC and Security sit on top of the network controller and play an active role making the network natively service-aware. We don't want our devices to just sit there and be passively programmable, putting the onus on our customers to figure out yet again how to benefit from SDN. The more important role for Radware is to be the application control point, and lead the industry in providing these control solutions for networks. Of course, our products also have RESTful APIs, so we can be easily integrated into any provisioning and orchestration platform."
SDNCentral: How do you see layers 4-7 and SDN interacting?
Avi: "In terms of SDN L4-L7 applications, our goal is to make the network more application aware to increase the value of the network as a whole. Our customers want to increase the value of the network assets they have.
It boils down to an efficiency argument. To reduce costs, you don't need 10 more appliances. You can leverage the power of the network elements but use a single application on the controller as the control and decision point. For example, we use the programmable OpenFlow flow tables on SDN network elements to inform our application about business application behavior. We also use other non-OpenFlow information in our decision-making process – prior to SDN this functionality could only have taken place on the ADC or security device.
I believe that the future of L4-7 is about injecting application awareness into the network. We're focused on bringing ADC and Security SDN applications that will program the network and thus make it smarter and more efficient. Another benefit of the SDN applications model is enhanced and straightforward automation of network and service operation, which reduces operating expenses when compared to solutions of the past."
SDNCentral: Specifically, how does your DefenseFlow SDN application work?
Avi: "DefenseFlow is a software product that leverages SDN technologies to provide DoS and DDoS protection as a native network service, alongside the Radware DefensePro Appliances. We start with security service provisioning by programming the security policy into the software-defined network elements. DefenseFlow utilizes flow rules and flow counters on SDN Controlled network devices to provide the information needed by the DefenseFlow application in order to program basic traffic forwarding capabilities. The overall solution combines a DDoS deep-inspection appliance (Radware DefensePro) with the power of an SDN network – which is tapped using the DefenseFlow Application. This allows customers to inspect the minimal amount of flows and use their existing L2/L3 network to block what is clearly malicious traffic or redirect suspicious traffic to the DefensePro appliances.
As an example, say we had 10K of flows exhibiting patterns that deviate from a historically established baseline. DefenseFlow, through the SDN controller will program the network to redirect these flows to the designated DefensePro appliance in order to analyze traffic from layers 4 to 7. By continuous synchronization between DefensePro and DefenseFlow, the accuracy to determine which flows are really malicious improves. Let's say DefenseFlow finds only 100 flows are malicious. It will update the SDN controller, and redirect fewer flows as time progresses. That's what we mean by bringing application-awareness to the network."
SDNCentral: Do you support all the controllers out there? How do you decide which controller to integrate with? What about OpenDaylight?
Avi: "Our key motivation here is to partner with the controllers our customers will end up using. Today we partner with all major commercial controller vendors, including IBM, NEC, Cisco, Big Switch, etc. OpenDaylight could possibly change the dynamics but however the outcome, we'll plan to contribute in our area of ADC and Security expertise.
Regardless, we're not sure how the controller landscape will evolve, so we are working with multiple controllers in parallel right now. If OpenDaylight becomes the de facto standard, then certainly it makes our job easier. Maybe we will narrow it down to two or three controllers in the future."
SDNCentral: Did you find any limitations in existing OpenFlow switches? How do you overcome them?
Avi: "Some of our switch partners do have limitations – mainly related to scalability. Eventually, the market needs to understand why customers need more flows and solve the flow-related scalability limitations. For us, to optimize the efficiency of SDN network elements, our SDN applications intelligently define small numbers of flows according to the topology and location of the switch/router and its role in providing us network intelligence.
For example, in our DefenseFlow application, to make the most efficient use of flow table entries, we use fine-grained counters on network elements that are close to protected business applications – such network elements can be vSwitches or NIC's – and we deploy much coarser grained flow counters on physical switches that are exposed to a far greater amount of flows. By not overburdening the edge switches with high-capacity flow table utilization, we reduce the impact on network performance. We don't count only on SDN enabled elements and use additional information from other network elements outside of SDN. After we analyze the information and make a decision, all this awareness is injected back into the network in order to handle redirection to the most relevant security resources and block traffic closest to the source."
SDNCentral: Beyond DefenseFlow, what other L4-7 services do you see interacting with SDN?
Avi: "Today, we are working on a few ADC applications. One is ElasticScale, which can provide on-demand ADC resource scaling based on dynamic service/application SLA. This lowers solution costs by only utilizing the amount of ADC resources needed, and by utilizing native SDN programming to dynamically optimize traffic distribution across ADC resources (likely virtual appliances) based on service/application SLA.
The SDN ADC application allows utilizing virtual and physical ADC resources across disparate networks to support global load balancing and disaster recovery scenarios as well."
SDNCentral: What do you see as the future with SDN and L4-7? Do you see L4-7 transforming into all software applications? What will happen to the hardware L4-7 devices?
Avi: "We see a mixed landscape going forward. For example, NFV (network function virtualization) will be all software. We're already seeing investment from Intel, HP and others to make it happen. At the same time, I don't think we will have a world where all L4-7 devices reduce to pure applications on SDN controllers. I'd expect a collaborative architecture with L4-7 appliances collaborating with apps on controllers that provide more value than before."