10 Deadly Interview Questions

If you are like most managers, interviewing is not your favourite task in the world. As a result, many managers avoid the topic. Yet, for something people dislike so much, it is one of the most important tasks a manager must execute. Hiring great people is critical to a company’s success. In a survey, Grant Thornton reviewed 1000 companies in the UK and found companies with the highest growth placed ‘having the best people’ as the most important factor contributing to their company’s growth.

Even more surprising is that in another study, only 8% of corporations in the US have any formal interview training program for hiring managers. When was the last time you had interview training from HR?  Since hiring is a task that comes around infrequently, once or twice every six months for most managers, there is little motivation to invest the time in training.

In absence of formal training the one thing we suggest you can do to improve your interviewing skill is: prepare. Spend 15 minutes before the meeting reviewing the job description, jotting down some questions to ask, and think about what information you need that is not in the resume. Interviewing can be easier than you think but like every successful meeting, it all starts with a well orchestrated plan. And if nothing else, please at least read the resume before the interview.

Still need some help? Here are some interview questions that may give some inspiration to step up your interview game.

1. Tell me why I should not hire you.

Probably one of the toughest question to ask and slightly unfair.  Answers are ripe with pit holes and can really throw a candidate off.  This question is designed to test their ability to think on their feet. The best answers are ones that take an apparent negative and make it positive.  Recommended not to start your interview with this question.

2. Rate yourself on a scale of one to ten.

Yikes, who wants to answer this one? If you give yourself a 6, then you are showing a lack of self confidence and you may not be hired. On the other hand, if you think you’re a 10, you may be labelled as unmanageable and miserably egotistical. The safest response is middle ground, between 8 and 9. This says they are confident, capable, and hard-working, but they know there is always room for improvement.

3. Everyone takes home the occasional pen from the supply room. What is the most expensive thing you’ve taken?

This is a great question to challenge someone’s moral compass. What makes this a tough question is that it implies everyone steals from their employers and that it is okay to do so. A person must be confident enough to challenge the first statement. Since the interview is usually stressful many people will let their guard and reveal the craziest things. Make sure you preface the question with the question with the initial statement; otherwise you are just accusing some of stealing.

4. Tell me about your greatest error in judgment.

A nice question to determine if your candidate is a model employee or if they have the ability to do the job correctly. The story they choose to tell in response should be unrelated to their previous jobs and should have occurred sometime in the distant past. Also they must be able to talk how they have grown and learned from this mistake. Choosing something recent and/or work related may highlight weaknesses and indicate incompetence.

5. What did you tell your boss to get the time off to come to this interview?

Great question to start the interview. It may seem like an icebreaker question, but they are establishing they integrity. They either declare themselves a liar or said they had a doctor’s appointment. The only answer to this question is they are there on their own time, either using a vacation day or part of their lunch hour.

6. Your Manager gives you a large important project to complete by end of day and the President of the company asks you to clean up the office for an important client coming in. What do you do?

This question is less about the answer given and more about a person’s ability to make a decision they can justify.  It also gives insight to prioritization. The natural response for most people is to do as the president asks. The candidate will ask themselves ‘what answer does this person want to hear?’ It becomes a dilemma for the candidate. Asking more questions to better learn about the scenario is a good sign.

7. Tell me about a situation in which you would be willing to take a pay cut.

Another killer question. Are they a team player, would they take one for the team, or are they here only for the money? This question can lead to many responses, but use it to drill down to learn about their money motivations.

8. What is more important: money or time off?

A simple question, but one that will without fail stump many candidates. If they answer the question with money, it will seem greedy and that they will leave at the first job offer that pays higher. If they choose time off, then they may feel that they would be perceived as a slacker. This is a trap question.

9. Have you ever been fired from a job?

Direct question few people are willing to ask directly. Use it sparingly. If the answer yes, do not jump to any conclusions; investigate more. There may be a good reason.

10.  Tell me about the job you hated the most

Using this question is only effective if the interviewer spends some time understanding why and exploring what the person was doing. Dig deep on the specifics of the job duties. Do not take a one or two sentence answer.

2015: The year SDN and NFV go mainstream

In 2015, we expect to see organizations begin to take steps to truly embrace software defined networking (SDN) and its sibling – network functions virtualization (NFV). What other technologies and trends might we see in 2015?

Much of 2014 was spent discussing software-defined networking (SDN), network functions virtualization (NFV), and other “new” networking technologies. We also heard debates about the merits of the Internet of Things and what it will do for the world; we wondered whether the Apple Watch would drive an uptick in smart wearables. 2014 was, to an extent, the year of chatter.

We spent a lot of time defining SDN at forums and forming new standards bodies, but it was not uncommon to hear customers, media, and service providers ask for something tangible amid the discussion of its benefits. After all, where were the mass deployments?

In short, 2014 was the year we strategically moved pieces around the board, but never reached the point of calling “checkmate.”

So will 2015 offer more of the same, or will we see winners emerge and the new networking ecosystem take shape?

SDN and NFV to crack ground in the telecommunications market

It’s safe to say the SDN and NFV era is still in its infancy. That will soon change, according to Infonetics Research’s “2014 SDN Strategies: North American Enterprise” survey, which estimates that 87% of U.S. businesses intend to have SDN live in their data centers by 2016. From that perspective, SDN is well on its way.

These deployments have kept the hype somewhat subdued, but this is the most transformative technology we have developed in decades, and 10 years down the line – maybe even sooner – SDN will simply be known as “networking.” In 2015, the technology will begin the journey down that path with the first deployments of SDN in telco networks across the globe. This will be a huge step and could push SDN toward achieving critical mass; we expect to even see SDN deployed on global submarine networks to enable more dynamic services than anything available in the past.

We will also begin to see NFV become a technology du jour. There were NFV whispers in 2014, but 2015 promises to put the discussion on the map in the same way SDN was during the past 12 months. Once people see the tangible results of what software can do for a network, it’s only a matter of time before people begin to see the benefits of replacing hardware functions with virtualized equivalents. Infonetics research backs up these predictions in its “Carrier SDN and NFV Hardware and Software Market Size and Forecast” report, which predicts that the NFV and SDN markets will reach $11 billion globally in 2018. Along with the major telcos announcing SDN deployments, we’ll also see initial NFV deployments in high-touch enterprises.

Time for an SDN Sequel? Scott Shenker Preaches SDN Version 2

Scott Shenker, one of the minds behind the creation of SDN, has some misgivings about the technology. It’s time for SDNv2, he says.

Speaking Wednesday at the Internet2 Technology Exchange conference in Indianapolis, Shenker explained that the first take on software-defined networking (SDN), which started taking form six to eight years ago, relied on some key “misconceptions.” That’s not an indictment of the SDN concept, just a sign that it could use some tweaking.

Shenker — who, along with Nick McKeown and Martin Casado at Stanford University, and others, developed OpenFlow and the ideas behind SDN in the mid/late 2000s — is working with other researchers (including McKeown again) on a set of technologies that he’s calling SDNv2, a second draft that takes into account Layer 4-7 equipment, the prevalence of virtual switching, and the rise of network functions virtualization (NFV).

But there’s an important caveat: SDNv2 targets carrier networks. They differ from data-center networks in that they’re filled with legacy equipment that won’t go away soon, and they’re equipped with a network core that’s built to forward packets quickly. His talk didn’t discuss the data center, where SDN-as-we-know-it might be working just fine.

At a time when we’re telling each other things are moving so fast, Shenker is disappointed that SDN has matured so slowly — more slowly than he expected, anyway.

The problem lies with SDN’s roots, he said. He and other researchers simply misunderstood the nature of carrier networks.

The Tenets of SDNv2

SDNv2 would still separate the control and data planes, and it would still aim for programmatic control of the network.

It differs from older SDN conceptions in three major ways (plus one more point of Shenker’s that I’m adding to this list). Keeping in mind that this is all about carrier networks, and not about settings such as Google data centers, those differences are:

1. Software goes to the edge; the core stays dumb. Implied in this statement: Switching at the edge becomes largely virtual, handled on x86 cores.

This can be done, Shenker insists. His calculations suggest that a major ISP’s traffic can be handled by $150,000 worth of x86 cores. (Other microprocessor architectures such as ARM‘s would be welcome here, of course, but Intel‘s x86 dominates the market.) Power consumption would increase compared with switch ASICs, but it would still be “infinitesimal” compared with the entire carrier network, he said.

Why is this different? Because Shenker and others started out assuming the network was homogeneous. The differences between core and edge switches — the existence of MPLS, essentially — wasn’t taken into account.

“This one is unforgivable. We just ignored current systems,” Shenker said. “One of the secrets, when you teach networking, [is that] nobody covers MPLS.”

2. “Middleboxes” get included in SDN. “Middleboxes” refers to the Layer 4-7 appliances, real or virtual, found all over the network.

SDN’s earliest incarnations didn’t take these into account, as Layer 4-7 vendors will tell you repeatedly. This was a shortcoming of the early jump to OpenFlow, which primarily manipulated Layer 2.

Under SDNv2, functions such as firewalls, load balancers, and WAN optimization would be included in the SDN edge, in virtual form. Sometimes they would be in the form of lookup tables, but more often, they would be virtualized network functions (VNFs) — which is where NFV gets folded into SDNv2.

This corrects the original SDN assumption that the data plane was dominated by routers and switches. In fact, Berkeley researchers including Sylvia Ratnasamy did a simple count of boxes and found carrier networks were just about evenly divided among routers, switches, and middleboxes.

“If SDN claims it is going to provide programmatic control over the network, then it has to incorporate these middleboxes,” Shenker said.

3. The network is opened up to third-party services. This is the biggie, and something that speaks to the purpose of SDN rather that the mechanics of it.

It means the edge of the carrier network would become analogous to Amazon Web Services: Anybody can check in, for a fee, and start using the network. Shenker calls this “service virtualization.”

It’s the crux of SDNv2, because it addresses carriers’ No. 1 problem: how to generate more revenues. New services are an obvious answer, but carriers are slow to develop new services and conservative about deploying them — and a service has to be a huge revenue generator, on paper, to even be considered.

By providing low-level interfaces into the network and a web-based, self-service portal, carriers could make money by having people pay to use the network as their own. Internet2 just announced a capability like this, in fact; its network virtualization lets any members take advantage of the 100-Gb/s Internet2 backbone.

Just as startups use AWS to avoid buying big chunks of computing power, they could use SDNv2 to rent out a carrier-sized network that they otherwise couldn’t afford. “If you had a setup like this, two kids in a garage could build a competitor to Akamai,” Shenker said.

4. Closed interfaces are not allowed. Shenker didn’t list this as an SDNv2 bullet point, but he was adamant about it later in his talk, and it seemed to resonate with the audience. “You do not have vendors offering vendor-specific interfaces at the edge,” he said — possibly a dig at Cisco‘s OpFlex, which became a multivendor effort but really did originate with Cisco.

SDNv2 Piece-Parts

Of course, Berkeley is working on a few elements to get all this done:

• Recursive SDN, which combines the best aspects of SDN and of global networks. SDN is being used on tens of thousands of switches at a time — but they’re all in a data center, all in the same place. Global networks have a wider reach, by definition, but they lack the fast failure recovery that’s vital to packet processing. Recursive SDN applies programmatic control to the hierarchy of a global network, initiating local responses to failures and using network virtualization to create new paths.
• The elastic switch (a name Shenker doesn’t like, but, too bad). This would be a self-managing group of equipment (not necessarily one switch) that sits at the edge and uses a combination of virtual switches and ASIC-based switching —because you’ll want both, Shenker said. The ASIC switches would be good for cases of fast-and-dumb forwarding that don’t need much packet processing.
• Various packet-processing improvements, such as better methods for fault tolerance. Shenker didn’t have time to get into details.
• Network verification for middleboxes. With routers, there’s a way to check if the routing tables are valid and don’t cause loops. Layer 4-7 equipment has no equivalent because they don’t operate on simple tables. They’re more like software programs, “and when you check collections of programs, you use model checking,” which really doesn’t scale, Shenker said. His team has found a framework that does work at scale, though; it can verify 35,000 middleboxes in five minutes, he said.

A Word About OpenFlow
So where does OpenFlow fit into all this?

OpenFlow itself isn’t a bad protocol, Shenker said. But OpenFlow was meant to communicate new ideas to networking equipment. The limitations of ASICs — table sizes, for instance — prevented OpenFlow from getting some of those ideas across.

“It’s not that the OpenFlow design is wrong. It’s that it was given an impossible task,” he said.

Shenker was also a founder of Nicira, a startup whose arc mirrors his misgivings about OpenFlow. Nicira began life as an OpenFlow startup but quickly shifted strategies toward network virtualization; it was famously acquired by VMware in 2012 and became the basis for the NSX product line.

Shenker thinks OpenFlow would eventually be a candidate to run SDNv2’s packet-forwarding core, but today’s MPLS would suffice for now.

Changing the Innovation Model

You can see how SDNv2 is tailored to the carriers, because it opens the door to new revenue sources without displacing the mass of legacy equipment that’s not going to be decommissioned any time soon. Specifically, the network core wouldn’t have to be touched at first.

But preserving the legacy network isn’t what SDNv2 is about, Shenker insisted. “Most importantly, this is about changing the innovation model” for SDN, he said.

So far, he’s not getting a good reception from the U.S. carriers, despite their need for new services. Foreign carriers have been more inviting, though, and he thinks that could spur some demand. “My guess is that once it gets deployed there, it will be much easier for American carriers to pick up,” he said.

Like the P4 protocol that could be a candidate for OpenFlow 2.0, SDNv2 is an academic exercise for now. But Shenker’s talk revealed ways to plug the gaps between the real world (especially the carrier reality) and SDN’s original assumptions. Even if SDNv2 doesn’t get off the ground, the points he brought up could prove valuable.

Cisco OnePK - Cisco Presents at Networking Field Day 5

What is Cisco onePK?



Using Puppet with Cisco onePK





Cisco ONE Controller History, Future, and Use Cases

Cisco Quad Sup VSS SSO demo



Cisco Catalyst 3850 Converged Access Switch Overview




Cisco Store-in-the-Box Demo with Kishan Ramaswamy



Cisco Identity Connector with OnePK Integration Demo with Natty Iyer


Cisco Private Datacenter Mobility Demo with Mostafa Mansour

Cisco Private Datacenter Mobility in depth with Mostafa Mansour


Cisco Wired and Wireless Demo




Free-Form Discussion on Hybrid Switching, OpenFlow, and SDN with Cisco

OTV - Quick Start Guide - Concepts & Configurations

Click Here to Download the Presentation

Top 10 Strategic Technology Trends for 2014-2015

Mobile and cloud hosting solutions are moving technology in new directions in 2014, as an infographic from ComputerSupport.com points out. Based on a report presented by Gartner at the Gartner Symposium/IT Expo, the infographic reveals ten clear strategic technology trends impacting businesses and consumers in 2014.

Mobile Device Diversity and Management

The rapid adoption of Bring Your Own Device (BYOD) in many workplaces has brought new challenges for security professionals. 2014 is the year professionals will realize the risks related to mobile devices and strengthen policies to address these risks.

Mobile Apps and Applications

Gartner predicts that apps will continue to grow in popularity and applications will start to dwindle as users go increasingly mobile. For developers, the push toward HTML5 and the browser as a delivery mechanism will change the development environment.

The Internet of Everything

For both businesses and consumers, internet connectivity will go beyond devices to include wearable items, household appliances, field equipment, and much more.

Hybrid Cloud and IT as a Service Broker

In its report, Gartner stresses the importance of bringing personal clouds and external private cloud services. Cloud environments should be set up with a hybrid future in mind.

Client/Cloud Architecture

The architecture of client/cloud computing is changing, with the client serving as the application on a PC or mobile device and the cloud requiring scalability. Applications must be able to run on multiple devices.

The Era of Personal Cloud

Thanks to the emerging personal cloud, services will become more important than services. While equipment will still be important, they will merely be a conduit to the apps and data a user needs.

Software Defined Anything

Known as SDx, Software Defined Anything encapsulates the networking, data centers, storage, and storage networks that make up technology today. SDx calls for improved standards for cloud computing and development.

Web-Scale IT

Calling upon the experience of large cloud providers like Amazon and Google, Gartner created a term called “Web-Scale IT.” This term refers to the need for enterprises to examine the IT value chain for improvements in every area across the organization.

Smart Machines

Devices will become more sophisticated through the year 2020 as machines like IBM’s Watson show more human qualities. Gartner predicts this smart machine era will be among the most disruptive in IT history.

3-D Printing

2014 will be the year mainstream 3-D adoption begins to grow, as the number of units shipped this year should grow by 75 percent. Gartner predicts this will be followed by double growth in 2015.

HOW IS THE SDN LANDSCAPE SHAPING UP? (PART-3) – A SECURITY PERSPECTIVE

Click Here - Part 1
Click Here - Part 2

In a fast-changing technology landscape, security is a moving target as the sophisticated attacker unearths and takes advantage of new weaknesses. Cybercrime has moved beyond mere vandalism and emerged as a professional industry focused on exploit kit innovations and planned attacks, given its lucrativeness and with some countries around the world involved in extensive cyber-espionage. The global hackers’ economy is pegged conservatively at around $450B, while Gartner estimates the worldwide security market for 2014 to be just about $71B.

In the December 2013 breach of retail giant Target, data from as many as 40M credit cards and 70M user accounts were hijacked, while Home Depot data breach between April and September 2014 affected 56M debit and credit cards, data of which is said to have appeared within days on black-market sites. Per Checkpoint security report 2014, 88 percent of analyzed organizations experienced at least one potential data breach event in 2013, up from 54 percent in 2012. Verizon’s data breach investigation report identified nine major patterns that covered over 90% of security incidents in the past decade, with the dominant pattern varying across industry verticals. [Refer bottom-right of the following chart for a listing of these categories.] In the recent years, dangers of targeted attacks and advanced persistent threats (APTs) have garnered much of the attention in the information security world.

How can SDN improve security?

With the increase in network traffic, virtual machines, cloud computing, and malware threats, IT manpower is a major security bottleneck, as they simply can’t keep up with the increasing demand of sorting through incidents/alerts and fine-tuning security controls based upon latest threats. This situation can be expected to exacerbate as IoT applications gain momentum. The only way to bridge this growing response-capability gap is through intelligent incident detection and automated response.

While automated security is a key driver, the excitement with SDN enabled security is more so around the opportunity for intelligent response on a granular basis – be it on per flow, per application or per user basis – to provide Security-as-a-Service, while eliminating manual configuration errors and keeping down SecOps & NetOps staffing costs. No longer would the default system response to any severe security threat be ‘Fully Block’.

Enterprise SecOps teams are interested in using SDN to enable multiple usecases – to selectively block malicious traffic from endpoints while still allowing normal traffic flows, to centralize security policy and configuration management, and for network security policy auditing and conflict detection/resolution.

With deperimeterization, corporate networks no longer have a single point of entry or exit, resulting in the demand for network telemetry and flow-based security solutions. SDN could be used to act on any anomalies detected on flow capture data, by dynamically establishing rules to divert specific flows to either a centralized or distributed enforcement points. Additionally, SDN could be used for traffic engineering to direct discrete network application flows to specific combination of security services such as FWs, IDS/IPS and WAFs.

SDN’s capability to programmatically and dynamically insert customized security services in the network path, via service chaining of physical and virtual L2-L4 routers/switches/appliances [as illustrated in below figure], could help minimize performance impact of ‘bump in the wire’ security devices, while enhancing security by acting on gleaned threat intelligence.

Figure – SDN enabled network and application security (Source: devcentral.f5.com)

While SDN controller limits its visibility and programmatic focus to underlying physical/virtual network elements and thus directly implements network security, application layer security is provided in this architecture by working in tandem with orchestration components to control other L4-L7 data path elements.

In a nutshell, SDN can help improve security by aligning the right security service with the right flows.

Common Security Usecases of SDN

Having gone over SDN security benefits in the previous section, let’s now deep dive into a couple of well-defined SDN security usecases – DDoS mitigation, Advanced Malware Quarantine and Elephant Flow mitigation.

DDoS Mitigation

Distributed Denial of Service (DDoS) attacks that are typically launched from compromised systems (bots) bombard enterprise applications with fake service requests, with the intent of denying or degrading performance of legitimate service requests. In addition to hogging the application servers, such attacks consume SP network capacity and saturate inline security devices. Addressing DDoS attacks requires detection of fake requests and diverting traffic to a specialized cleaning device to remove fake packets from the traffic stream, and sending back legitimate packets to the enterprise application/service.

While DDoS defense can be implemented through Remotely Triggered Black Hole (RTBH) or Policy based routing (PBR), the former solution implements filters that block all traffic to the target application, thus making it unavailable for legitimate services too. On the other hand, while static PBR based solution provides granular flow control, it requires SPs to add manual filter configuration on their backbone/edge routers and thus prolongs the recovery time from such attacks.

In comparison, BGP FlowSpec which aligns with the SDN paradigm follows a more granular approach and automates distribution of filter lists that can match a particular flow via BGP NLRI to the backbone/edge routers. So, policy updates happen dynamically and only a specific flow traffic (based on L3/L4 information) is stopped instead of dropping all traffic to a server, as illustrated in the below figure. SDN can thus boost security by dynamically reprogramming and restructuring a network that is suffering a distributed denial-of-service attack.

Figure – DDoS Mitigation using BGP FlowSpec (Source: Alcatel-Lucent)

Automated Malware Quarantine (AMQ)

SDN can also offer security capabilities such as automatically quarantining an endpoint or network that has been infected with malware.

In the non-SDN architecture, AMQ is typically deployed as a proprietary standalone solution where each device performs its specified function autonomously, with limited awareness of other devices in the network. This closed approach is suitable only for static traffic flows, and inflexible in data center environments where server workloads are virtualized, traffic flows are highly dynamic and multiple simultaneous flows must be maintained.

In a SDN controller driven network, if detailed forensics by network security devices generate a high enough score to initiate a quarantine directive, the SDN controller translates this into a set of OpenFlow rules that is pushed down to OpenFlow enabled switches to cut off the infected host from the production network and display (via the Web Proxy Notifier in the below figure) a web page with corrective actions to be performed. Once the corrective actions are performed, the rules are changed to allow the end host back into the network. Such automated reconfigurations through SDN reduce the response time to security threats, while allowing user mobility at the network edge. Given that this AMQ implementation does not require any additional software or hardware support beyond OpenFlow enabled devices, this is a vendor agnostic solution and ripe for deployment.

Figure – Advanced Malware Quarantine using SDN (Source: ONF)

Elephant flow detection/mitigation

Short-lived flows referred to as mice tend to be bursty and are often latency sensitive. In contrast, long-lived flows termed as elephants normally perform transfers of large blocks of data and are typically packet latency insensitive. Without intelligent traffic engineering, elephant flows may fill up network pipes causing latency and/or service disruption of mice flows.

SDN applications could help select a marking action and instruct the SDN controller to push the action to OpenFlow routers/switches to assign a selected queue for traffic associated with elephant flows. Other applications include offloading elephant flows from L2/L3 network fabric to the optical circuit switched network i.e. a pure photonic layer 1 network, for better performance and scalability at lower cost. In an enterprise environment, elephant flows observed during network backup of a filesystem could be prevented from taxing the firewall and slowing down its performance without compromising on security, by implementing a firewall service bypass function dynamically via SDN, based on whitelisted flow parameters of “good” permitted elephant flows. The permitted elephant flows are now dynamically re-directed so that they are sent directly in/out of the campus and the firewall is no longer in the forwarding path.

Security-centric SDN offerings

While OpenFlow is a key technology enabler of SDN security usecases as we saw in the previous section, few firms offer enhanced SDN security solutions that go beyond OpenFlow.

Illumio – a promising startup with a veteran executive team from Cisco, McAfee, Nicira, Riverbed and VMware – is based on the idea that each workload must have its own defenses. Illumio’s Adaptive Security Platform (ASP) provides visibility and enforcement services to dynamically keep pace with the motion, change and automation of the underlying IT infrastructure and applications, by attaching fine-grained security at the level of individual workloads while being continuously aware of its context. [Refer below figure to understand workload context.] It allows enterprises to secure applications across private, public or hybrid cloud environments on any physical server or VM. Illumio has 25 customers including Morgan Stanley, Plantronics, Creative Artists Agency, UBS, Yahoo and NTT I3.

Figure – Workload context (Source: Illumio)

Illumio ASP provides two modes of operation: (1) illumination mode which security administrators can use to visualize workloads and traffic flows, perform policy analyses, assess security gaps and potential impacts to application flows, and even discover unused workloads. (2) enforcement mode which lets administrators write security policies using natural language to describe desired communications between workloads. Once the policies are enforced, workloads are locked down to interact only with the specifically allowed paths.

As illustrated in the below figure, Illumio ASP is architected as a distributed and asynchronous system with Virtual Enforcement Nodes (VENs) attached to individual workloads (running on any VM, physical server, or private/public/hybrid cloud) and a centralized policy engine (PCE). The VENs listen continuously for the context of their workload and relay the information to the PCE, which computes enforcement rules by combining the workload’s context with configured security policies. The enforcement policies are then sent to the VEN, which modifies the appropriate iptables or Windows Filtering Platform parameters on the workload.

Figure – Security-centric SDN – Illumio ASP architecture (Source: Illumio)

NetOptics, a provider of application and network visibility and monitoring solutions, offers Security-centric SDN by combining an SDN controller with Network Packet Brokers (NPBs) in an architecture that allows for intelligent orchestration of the customer’s existing security appliances and solutions. NPBs embody dynamic attack monitoring, ability to chain solutions and distribute traffic, while the SDN controller is used to assess the network and adapt the network behavior based on threats detected through security enforcement elements, to either divert suspicious traffic, change security devices’ responses, or block packets altogether, all with minimal-to-no human intervention.

Radware’s Defense4All, the first open SDN security application to be integrated into OpenDaylight, offers carriers and cloud providers DoS and DDoS detection and mitigation as a native network service. The application uses the programmability of SDN to collect statistics, analyze information and control the infrastructure layer to proactively defend against network flood attacks. This allows operators to provide DoS/DDoS protection service per virtual network segment or per customer.

In today’s dynamic cloud data centers, assets and their network configurations are subject to change yet compliance lacks automation and continues to rely on manual processes. Catbird, the leader in security policy automation and enforcement for private clouds and virtual infrastructure, offers CatBird vSecurity to bring automation and agility of the cloud to security automation and enforcement of compliance standards such as PCI, HIPAA and FISMA. By integrating with Cisco ACI, Catbird provides IT teams a highly standardized, automated approach to provisioning security as part of the network policy, through the asset lifecycle from asset inception to teardown.

Most vendors including Juniper (Altor Networks acquisition rebranded as Firefly Perimeter) and Cisco offer SDN controllers that seamlessly integrate with virtual and physical routers/switches/security devices to enable dynamic provisioning and service chaining of security services. Among the vendors that have already announced OpenDaylight Helium-based products is Brocade. Helium release has multiple security capabilities including Secure Network Bootstrapping Infrastructure (SNBI) and AAA. Alongside, we have OpenFlowSec, a community focused on developing OF security applications, kernel extensions and application frameworks, to assist OpenFlow practitioners in enhancing security capabilities of OpenFlow.

Is SDN secure enough, to offer security?

We’ve seen that good potential exists to enhance security through SDN, and there are ongoing industry efforts to help realize it. But, is SDN inherently secure enough, to augment network and application security? Or is SDN security an oxymoron as skeptics put it? Let me explore this aspect to try and calm down the naysayers to SDN from a security perspective, before I wind up this post.

Here are the top security concerns of the SDN architecture –

1. Single point of failure, given the central function of the SDN controller
2. Wide span of impact, when the network is opened up to applications
3. Need for secure communication between controller and end nodes/applications, to stem MITM attacks

Single Point of Failure

Because the control plane and thereby the SDN controller play such a central function in the SDN architecture, security strategies must focus on protecting the control plane to thwart any targeted attacks on the controller – be they to saturate the control plane or attempts to leverage policy configuration errors for infiltration and lateral movement – as access to the controller could potentially give complete control of the network to an attacker.

It is vital to secure the SDN controller by carefully designing access control policies, manage authorization, track and audit usage of the controller. Also, where it resides on the network is a big security concern. This concern of having a king that needs to be protected are being addressed in variants of the SDN architecture through High Availability in the controller, SSL communication between controller and network elements, extension to the OpenFlow data plane called connection migration, which dramatically reduces the amount of data-to-control-plane interactions that arise during such attacks, SIEM to log everything that comes out of the system, analytics to correlate logs from SIEM and alert the manager of any changes.

Wide span of impact

In contrast to pre-SDN one-by-one configuration process, where an error might only affect one part of the network, SDN now makes it easy to have one policy applied uniformly and in an automated way. However, opening up the network to its own applications require their own security policy framework, governance and management to be put in place.

Business applications are vulnerable to potential threats because of the powerful SDN programming model. Multiple SDN network services may interfere with one another, compromising the forwarding behavior of the network and such conflicts must be avoided. Security policies may be compromised at the controller, at one or more network devices, and/or at other places. As a result, security policies must be validated, along with the network configuration and behavior and performance.

While the upside is that SDN will demand clear policies, companies will need to spend time thinking about and designing those policies. These can be expected to be reside as pre-provisioned security policy logic in a policy management system.

Communication between controller and end nodes/applications

To thwart any security barriers to SDN adoption, OpenDaylight community launched a project to analyze current security capabilities of its SDN implementation, and provide recommendations for security enhancements. Below is a quick snapshot of the transport layer security of existing northbound (NB) and southbound (SB) plugins. For example, OpenFlow specifies the use of TLS or UDP/DTLS, which support authentication using certificates and encryption to secure the connection.

Figure – Transport Layer Security capabilities of SB & NB protocols (Source: ODL)

OpenDaylight recommendations for SDN controller security that are implemented in Helium and future releases include:

• AAA service for applications/users/devices
• Framework to securely and automatically discover, connect and configure the devices
• Secure mechanism to cluster the controller for scalability and availability
• Robust incident response support for controller/devices/user. E.g. A southbound syslog plugin to incorporate capture logs from devices in incident analysis
• Secure communication channel to connect to plugins, common trusted crypto key storage for all plugins, pluggable or built-in Certificate Authority

How is the scale tilted?

Securing networks is becoming more challenging to businesses, especially with BYOD and increased cloud adoption, if not yet due to other mass phenomena such as Internet-of-Everything. Organizations can certainly protect themselves better through automated and dynamic security solutions made possible through SDN, as it provides a centralized intelligence and control model that is well suited to provide much-needed flexibility to network security deployments.

With SDN, we can add agility to network intrusion responses and go beyond the network to protect what is actually of interest, namely applications. Focus on network security was more an interim arrangement as there existed a network visibility deficit at the higher layers. However, by focusing on the network all these years, we lost the most important context awareness which will help deduce if the application or user is doing what is allowed to be done. Security-centric SDN allows an organization to deploy a quick, decisive and deep enterprise-wide response to threat on all fronts. An integrated solution comprising both network and application-layer elements will ultimately provide the comprehensive ‘top-to-bottom of the stack’ security desperately needed to defend against attackers in the dynamic threat landscape.

The key to realizing self-defending networks, however, is “lower false positives” combined with “actionable-threat-intelligence”, given the lack of human element to weed out false alarms or manually correlate event logs to decide on the course of action, in the SDN driven security architecture.  The ecosystem of network security vendors, threat intelligence providers, and security professionals should strive for highly accurate intelligence so that automated security remediation decisions are made with a high-degree of confidence. Also, SDN technologies will need to continually evolve to enhance their inherent security capabilities to avoid being a dampener to adoption.

Adoption of SDN will force NetOps and SecOps to work together more closely, even if they aren’t merged into a single organization as few propose or atleast foresee to happen. This could be a bigger change than the driving technology per se, and one that could meet with opposition, given the organizational dynamics involved. Let’s wait and watch how these play out and if enterprises are able to tap into security-centric SDN benefits.

Meanwhile, how do you think the balance is tilted? Will security drive or hinder SDN adoption? Also, a clarion call to security professionals out there to critique my post. Look forward to learning from your feedback too, while I try to get a better handle on security.

HOW IS THE SDN LANDSCAPE SHAPING UP? (PART-2) – A MARKET PERSPECTIVE

Click Here - Part 1

Will SDN and its accompaniments (NFV/NV) bring back the glorious days prior to the telecom bust, and pull the networking industry out of its technological plateau? I presume, most would say that the wave has already started. It is surmised that SDN has brought back venture money to networking after years of drought, years that were mostly sustained by bigwigs of the industry, through spin-ins and strategic investments in startups. SDN has found huge favor with VCs, with startups in this space having raised nearly $500M in 2013. Successful exits in the last couple of years, including Nicira Networks (VMWare), Contrail Systems (Juniper), Vyatta (Brocade), Tail-f (Cisco), Xpliant (Cavium)  and Cyan (IPO), have further spurred VC funding in the SDN market.

What business potential does SDN hold?

To start off with vendor perspective, there are 2 facets to be understood –

• How will SDN impact customer spending in existing market?
• What is SDN’s potential for new market creation?

Roughly 30% of the total networking spend from Service Providers, Enterprises and Web Hosting companies is expected to be related to SDN. So, existing market players need to buckle up and be ready with committed SDN roadmaps and solutions, to still be relevant in the SDN driven networking market, as the technology is emerging as a significant influencer in network purchasing decisions. Customers are increasingly seen to evaluate how solutions and equipment procured today will fit into an SDN environment in the future. Market research firms (and VC firm Lightspeed Venture Partners) forecast impact of SDN to exceed $25B per annum, which could potentially be as high as $35B, by 2018. In comparison, the overall networking TAM is estimated to grow from the current value of $75B to $90B by 2018.

Figure - SDN existing market impact (Source: Plexxi)

Except for speeds and feeds, networking innovation has been lagging behind compute (servers) and storage, the other two key blocks in any data center infrastructure. The advent of SDN/NFV/NV should help effectively virtualize any IT infrastructure environment by complementing compute and storage solutions, and propel new market creation, at a pace faster than seen with server virtualization in the mid-2000s. According to IDC, the new SDN market TAM will reach a total value of $3.7B by 2016, and touch $8B by 2018.

Figure - SDN new market potential (Source: IDC, Image Source: IT World)

Moving on to customer perspective, SDN assures businesses outcomes of better revenues (by enabling network monetization through improved service velocity), and lower TCO (through automated control and higher network resource utilization). As with any emerging technology, customers are apprehensive whether SDN can deliver on its promises, and are unsure of its potential to become mainstream. Broad incumbent support for SDN and significant open community efforts are expected to accelerate maturation of SDN technology, and help realize usecases.

While SDN related needs have mostly been latent, Google (a founding member of ONF) developed an in-house solution for its inter-datacenter WAN deployment with centralized traffic engineering, using OpenFlow based SDN, as early as 2012. Other marquee SDN adopters include Amazon, eBay, Rackspace and Baidu.

What are the leading usecases?

Key usecases for SDN include public & private cloud, WAN traffic optimization, dynamic WAN interconnects and re-routes, network virtualization, automated network management, service chaining, network analytics, automated malware quarantine, granular flow based DDoS mitigation et al. 

The usecases span Data Centers, Enterprise campuses, Cloud Providers, Service Providers and even SMBs, as latter segment could amply gain from SDN’s value proposition of IT infrastructure simplicity.

It wouldn’t thus be an exaggeration to conclude that SDN is going to impact every customer segment and use case of the networking market, and thus no customer or vendor is going to be immune to SDN driven change.

The Ongoing Controller War

SDN has driven the emergence of a new class of products, the SDN controller. With the controller being a strategic control point of any SDN network, vendors are vying for significant mindshare of their respective SDN architecture and controller solution, to eventually translate it into a sizeable market share.

Most dominant vendors in the industry are working on their own controller offerings [Refer next section for list of SDN controllers] to better chart the course of controller evolution and development, turn on potential software differentiation and hardware-assist features, and effectively orchestrate their range of infrastructure equipment offerings.

In addition, vendors (in collaboration with the Linux Foundation) have created an open-source platform for SDN, the OpenDaylight Project (ODP), to enable SDN adoption by accelerating technology development through ODP’s Open Controller.

A community-driven, common and trusted Open Controller would ensure network component interoperability across vendor offerings, both within and across architectural layers. The goal is also to promote multi-vendor environments, in comparison to today’s networks where each tier is typically populated with single vendor solutions. Network architects have been advocating open source/standard approaches to liberate customers from vendor lock-in challenges. Customers such as cloud and internet service providers, using such open standards based solutions, could still differentiate their end user offerings, by incorporating their secret sauce in the application layer. 

Arguably, vendors who do not have their own controller but are participating actively in OpenDaylight community efforts seem to be betting the most for ODP controller to take off. Meanwhile, the controller war has heated up with the entry of other open source controllers which have been making news, namely Juniper’s OpenContrail and ON.LAB’s ONOS.

So, let us take a quick look at how these controllers differ.

ODP architecture has a single uber-controller and is primarily datacenter focused today, but could service WAN usecases as well.

ONOS targets SP WAN usecases with an architectural focus on fault-tolerance and state distribution across multiple controllers, to address high availability and bottleneck concerns with a single uber-controller. The challenge here is the need to orchestrate among these multiple controllers.

OpenContrail architecture is built for centralized control but with distributed physical components for fault tolerance. OpenContrail is very routing centric and focused on solving multi-tenant issues for SPs. Experts opine that its scope to extend to other customer segments is limited, given the lack of an abstraction layer to support multiple southbound/northbound interfaces, unlike ODP. 

With vendors and communities tweaking their architectures and evolving their solutions over time, it is early to predict any potential winners. With SDN deployments being sporadic till date, it will be sometime before contenders evolve their offerings, prove their mettle in actual deployments and emerge successful.

The gamut of SDN offerings (ODP/ONF members only)

Given that there is a whirlwind of SDN activities in every nook and corner of the industry, I’ve opted to limit my evaluation to current members of ODP & ONF. To get a feel of the number of firms out there in the SDN ecosystem, refer list of players.

With SDN taking the world by storm [well, that might have be an exaggeration though - just got carried away for a bit, but here is what I wanted to say], I think it is inevitable for networking vendors to make their existing HW equipment and OS offerings SDN-ready, if they don’t want to be left behind. Also, a new group of players have emerged with niche SDN applications and orchestration platforms (e.g. PLUMGrid with its OpenStack Networking Suite).

While adding SDN capability to (legacy/existing) equipment and appliances would ensure investment protection for customers, SDN and orchestration applications (which are still taking shape and quite customer/segment specific) are key to delivering real customer value through SDN. However, adoption of SDN controllers, the pivotal component in the SDN architecture, is a precursor for customers to tap into potential of SDN applications.

I’ve chosen to focus my analysis in this post, on SDN offerings from (1) those who’ve taken the plunge by putting out (or working on) SDN controllers in the market, and (2) those who have built pure software switches, that can go with generic (x86?) hardware, towards realizing the joint vision of SDN/NFV/NV.

And, here we go with the list of SDN offerings!

(1) SDN Controller Platforms

Just a quick reminder that SDN controllers are only software platforms. And, yes, they do need a host to run on. 

I’ve removed the term ‘Controller’ from product names in the below table. Thought it was understood.

DBSM	OBelle	Big Tap
Brocade Vyatta	Agility Multilayer WAN (MLWC)	XNC (ODP based), ONE, APIC (Insieme)
NetScaler	Intelligent Optical Control (IOC)	Blue Planet
Active Fabric	ETRI	ODP-based with extensions
Virtual Application Networks	Carrier-class SDN (SNC)	Programmable Network (PNC)
Sustainable SDN (ODP-based)	OpenContrail, NorthStar Network (NNC)	Virtual Network (VNC2.0)
Programmable Flow PF6800	Ryu OpenFlow (used by Pica8 too)	Virtualized Services (VSC)
Oracle	Plexxi Control	NSX (Nicira)
	OpenDaylight (ODP)

(2) SDN Packet Processing Platforms

Here is the list of software-based SDN packet processing platforms, built to run on generic hardware. These would technically fall under the gamut of SDN-ready NFV products, though they align with SDN vision.

6WindGate	Fast Path Accelerator	Switch Light
Vyatta 5400/5600 vRouter	Cisco vPE-F	Hyper-V vSwitch
MidoNet	ProgrammableFlow vSwitch	Integrated Open vSwitch

Interestingly, the ecosystem has also seen the entry of Intel into Ethernet switch market, with FM5000/FM6000 series of SDN-enabled ASICs.

Commercial SDN deployments

Now, let me run SDN through the market adoption test!

As we saw, there is no dearth of SDN offerings in the market. But, but, has SDN really taken off? I chose to evaluate this based on public customer references. I thought I’d be amply surprised if any vendor deployed SDN commercially and didn’t get their marketing folks to put together public customer references, or if carriers/web hosting companies didn’t want to make a splash of having adopted SDN. And well, I was surprised. Anyways, more on this later.

Going based on public references, here are the commercial SDN deployments of vendors. I’ve kept out in-house SDN solutions developed/deployed by customers such as Google, NTT, AT&T, Amazon, Microsoft, Facebook, given the number of makeshift offerings masquerading themselves as SDN solutions, and the many paths to realizing SDN benefits of programmability and improved service velocity.

SDN Vendors	Customers	Deployment Usecases
		SP Carrier Network
		Private Cloud
		Data Centers
		Cloud Data Centers
		Cloud Data Centers
		Data Centers (Prior to VMWare acquisition)
		Data Centers (Prior to VMWare acquisition)

Additionally, Cyan reports on its website that Blue Planet SDN platform has been implemented in 120 production networks, but I didn’t come across any other public material.

Seems too short a list right? Either these are the only commercial deployments or public references aren’t the way to go. Didn’t think that SDN customers (and not just startups like Versa Networks, GuardiCore) would be in stealth mode. If you know of any more SDN deployments, please point me to public references online.

If you could spare time for a deep-dive, do take a look at the links I’ve embedded (at the start of this section) on in-house SDN solutions being worked on by SDN “customers”. Interesting to see how boundaries are continuing to blur across vendors and customers!

May the best win (or atleast each find their niche) and the ecosystem prosper!