Tag: orchestration

5G network slicing: How to secure the opportunity

Network slicing is central to unlocking the 5G opportunity

There has understandably been a lot of talk and hype about 5G and network slicing in the telecoms industry. It promises to bring greater speeds, lower latency, greater capacity, ultra-reliability, greater flexibility in the network operations and more. It also pledges to support high device densities and to enable new services, new business and operational models as well as new vertical opportunities.

Given that the rollout of 5G networks is expected to involve a significant investment of hundreds of billions of dollars, there is a need to look at how it might address new business opportunities that previous generations of cellular networks could not. Many, including us, have argued that the consumer business case for 5G is limited, and that the enterprise segment is likely to represent the greater opportunity.

One highly anticipated aspect of 5G is that it will be built on virtualised infrastructure. Network functions will run as software in datacentres, rather than on dedicated appliances as in the past. This will mean that operators can deploy and make changes to functions with far greater flexibility than ever before. It also offers the promise of enabling multiple logical end-to-end networks – each intended to meet specific needs – to be “spun-up”, operated and retired as required, over the same shared hardware. Traditionally, achieving such a multi-service outcome would have required building dedicated stand-alone networks, which was rarely a viable proposition.  This capability is the essence of network slicing.

Figure 1: Diagram of network slicing

5G network slicing diagram

Source: STL Partners

This report will explore the concept of network slicing and what it means for enterprise customers. It will have a particular focus on one aspect of network slicing through the enterprise perspective, that being security. The first section will cover how we define network slicing whilst the second will dive into what the enterprise security-related concerns are. We will then assess the implications of these concerns in the third section, before identifying ways that telcos can address these concerns in order to accelerate the adoption of network slicing.

Our findings in this report are informed by a wider STL Partners research programme that STL Partners has conducted with telcos and enterprises across several verticals, including transport, defence, utilities, logistics and smart cities.

Enterprise security concerns with network slicing are rooted in the fear of the new and unknown

Network slicing is inherently complex. Multiple networks being created over common infrastructure, each serving different customers, use cases and devices means that management and orchestration of network slices is something that telcos are still grappling with. It not only represents a change in technology but also a shift in the way that the network lifecycle is managed, which is new and unfamiliar to telcos and their enterprise customers. Current security protocols will not necessarily be equipped to cover many of the new dimensions that network slicing brings. This new shift in the way things work will result in various enterprise security concerns. Changes in the network architecture with slicing, with multiple logical networks each having their own resources and sharing others, also poses questions of how the security architecture needs to evolve in order to address new risks.

Enterprise customers define security as not only about preventing services being compromised by intentional malicious attacks, but also about preventing service degradation or disruption due to unintentional operational or technical failures and/or negligence, unplanned breakdowns etc. Due to the interdependence of slices, even if a fault occurrence happens, it could consume resources in one slice, just like an attack would, which would affect the reliability or lifecycle of other network slices that share the same resources. Regardless of how the performance of a slice gets affected, whether it is by a malicious attack, a natural disaster, a bug or unintentional negligence, the consequences are ultimately the same. These are all, in some way, related to security. Therefore, when considering security, we need to think beyond potential intentional malicious attack but also unintentional negligence and unplanned events.

What if my network slice gets compromised? What if another slice gets compromised? What if another slice is eating up resources?

We outline these three key questions that enterprises have around their security concerns, as potential tenants of network slices, in the body of the report.

Table of contents

  • Executive summary
  • Introduction
    • Network slicing is central to unlocking the 5G opportunity
    • Dynamic, virtualised, end-to-end networks on shared resource
    • Slicing might come about in different ways
    • Slicing should bring great benefits…
  • Enterprise security concerns with network slicing are rooted in the fear of the new and unknown
    • What if my network slice gets compromised?
    • What if another network slice is compromised?
    • What if another network slice is eating up resources?
  • Security concerns will slow adoption if not addressed early and transparently
    • Concerns and misconceptions can be addressed through better awareness and understanding
    • As a result, enterprises project concerns about public networks’ limitations onto slicing
    • The way that network slicing is designed actually enhances security, and there are additional measures available on top.
  • Telcos must act early and work more closely with customers to drive slicing adoption
    • Ensure that the technology works and that it is secure and robust
    • Organise and align internally on what network slicing is and where it fits internally before addressing enterprise customers
    • Engage in an open dialogue with enterprise customers and directly address any concerns via a ‘hand holding’ approach
    • Don’t wait for maturity to start testing and rolling out pilots to support the transition and learning process
  • Conclusion

The Devil’s Advocate: SDN / NFV can never work, and here’s why!

Introduction

The Advocatus Diaboli (Latin for Devil’s Advocate), was formerly an official position within the Catholic Church; one who “argued against the canonization (sainthood) of a candidate in order to uncover any character flaws or misrepresentation evidence favouring canonization”.

In common parlance, the term a “devil’s advocate” describes someone who, given a certain point of view, takes a position they do not necessarily agree with (or simply an alternative position from the accepted norm), for the sake of debate or to explore the thought further.

SDN / NFV runs into problems: a ‘devil’s advocate’ assessment

The telco industry’s drive toward Network Functions Virtualization (NFV) got going in a major way in 2014, with high expectations that the technology – along with its sister technology SDN (Software-Defined Networking ) – would revolutionize operators’ abilities to deliver innovative communications and digital services, and transform the ways in which these services can be purchased and consumed.

Unsurprisingly, as with so many of these ‘revolutions’, early optimism has now given way to the realization that full-scope NFV deployment will be complex, time-consuming and expensive. Meanwhile, it has become apparent that the technology may not transform telcos’ operations and financial fortunes as much as originally expected.

The following is a presentation of the case against SDN / NFV from the perspective of the ‘devil’s advocate’. It is a combination of the types of criticism that have been voiced in recent times, but taken to the extreme so as to represent a ‘damning’ indictment of the industry effort around these technologies. This is not the official view of STL Partners but rather an attempt to explore the limits of the skeptical position.

We will respond to each of the devil’s advocate’s arguments in turn in the second half of this report; and, in keeping with good analytical practice, we will endeavor to present a balanced synthesis at the end.

‘It’ll never work’: the devil’s advocate speaks

And here’s why:

1. Questionable financial and operational benefits:

Will NFV ever deliver any real cost savings or capacity gains? Operators that have launched NFV-based services have not yet provided any hard evidence that they have achieved notable reductions in their opex and capex on the basis of the technology, or any evidence that the data-carrying capacity, performance or flexibility of their networks have significantly improved.

Operators talk a good talk, but where is the actual financial and operating data that supports the NFV business case? Are they refusing to disclose the figures because they are in fact negative or inconclusive? And if this is so, how can we have any confidence that NFV and SDN will deliver anything like the long-term cost and performance benefits that have been touted for them?

 

  • Executive Summary
  • Introduction
  • SDN / NFV runs into problems: a ‘devil’s advocate’ assessment
  • ‘It’ll never work’: the devil’s advocate speaks
  • 1. Questionable financial and operational benefits
  • 2. Wasted investments and built-in obsolescence
  • 3. Depreciation losses
  • 4. Difficulties in testing and deploying
  • 5. Telco cloud or pie in the sky?
  • 6. Losing focus on competitors because of focusing on networks:
  • 7. Change the culture and get agile?
  • 8.It’s too complicated
  • The case for the defense
  • 1. Clear financial and operational benefits:
  • 2. Strong short-term investment and business case
  • 3. Different depreciation and valuation models apply to virtualized assets
  • 4. Short-term pain for long-term gains
  • 5. Don’t cloud your vision of the technological future
  • 6. Telcos can compete in the present while building the future
  • 7. Operators both can and must transform their culture and skills base to become more agile
  • 8. It may be complicated, but is that a reason not to attempt it
  • A balanced view of NFV: ‘making a virtual out of necessity’ without making NFV a virtue in itself