PaperlayerView exact revision on arXiv

Source-linked AI summary

Towards Secure Slicing: Using Slice Isolation to Mitigate DDoS Attacks on 5G Core Network Slices

Danish Sattar, Ashraf Matrawy

arXiv:1901.01443v2cs.NI

TL;DR

Shared physical resources in virtualized 5G networks let a DDoS attack on one slice affect others. The paper models on-demand slice isolation and end-to-end delay constraints; its evaluations report improved mitigation, with complete isolation best in both tested attack scenarios. The results also identify a trade-off between strong isolation and efficient resource use.

  • Problem

    Shared physical resources in multi-tenant 5G networks allow a DDoS attack on one slice to disrupt services on other slices.

    Source: §I · p. 2

  • Method

    A security-focused optimization model allocates slices using isolation constraints and end-to-end delay requirements.

    Source: §I · p. 2, C. General Constraints · p. 5

  • Results

    Complete slice isolation provides the best mitigation in both evaluated attack scenarios, while intra-slice isolation levels Krel = 1 and Krel = 2 significantly reduce response-time and round-trip-time impacts versus NoIsolation.

    Source: §VIII · p. 9

  • Takeaways & Limitations

    Inter-slice isolation provides strong resource isolation but can reduce resource-use efficiency, while intra-slice isolation offers more control over the security, availability, and utilization trade-off.

    Source: §VIII · p. 9

    The allocation scheme is static and does not re-allocate previously allocated slices to use available resources more efficiently.

    Source: C. Current Limitations · p. 9

Abstract

from arXiv · show

In this paper, we propose a solution to proactively mitigate Distributed Denial-of-Service attacks in 5G core network slicing using slice isolation. Network slicing is one of the key technologies that allow 5G networks to offer dedicated resources to different industries (services). However, a Distributed Denial-of-Service attack could severely impact the performance and availability of the slices as they could share the same physical resources in a multi-tenant virtualized networking infrastructure. Slice isolation is an essential requirement for 5G network slicing. In this paper, we use network isolation to tackle the challenging problem of Distributed Denial-of-Service attacks in 5G network slicing. We propose the use of a mathematical model that can provide on-demand slice isolation as well as guarantee end-to-end delay for 5G core network slices. We evaluate the proposed work with a mix of simulation and experimental work. Our results show that the proposed isolation could mitigate Distributed Denial-of-Service attacks as well as increase the availability of the slices. We believe this work will encourage further research in securing 5G network slicing.

I. INTRODUCTION

Shared virtualization lets 5G slices use common physical infrastructure, so a DDoS attack on one slice can disrupt others. The paper proposes slice isolation and an optimization model to mitigate attacks while meeting delay and resource-allocation objectives.

I. INTRODUCTION

  • A DDoS attack on one slice can disrupt other services when slices share virtualized infrastructure, making isolation a key 5G slicing requirement.The paper identifies shared links and co-hosted slices as cross-slice attack paths.Source: §I · pp. 1–2
  • The paper proposes inter-slice and intra-slice hardware isolation, end-to-end delay guarantees, and efficient slice allocation as contributions.Inter-slice isolation separates host hardware between slices; intra-slice isolation separates a slice’s components across hosts.Source: §I · p. 2
  • Inter-slice isolation prevents a DDoS on one slice from impacting others, while intra-slice isolation can improve availability and speed service recovery.Recovery may involve migrating only affected slices rather than deploying reactive defenses for all slices.Source: §I · p. 2
  • The proposed security-focused optimization model is evaluated through simulation and experiments, and the study focuses on 5G core slicing rather than RAN slicing.The model aims to provide isolation, meet end-to-end delay requirements, and use available hardware efficiently.Source: §I · p. 2

II. RELATED WORK

Prior work addresses several aspects of 5G slicing security and VNF placement. The paper then sets out its threat-model assumptions, including support for virtualized, multi-tenant slicing and configurable slice components.

II. RELATED WORK

  • Related work covers secure intra-slice communication, security-focused auto-scaling, IoT authentication, quantitative isolation analysis, and VNF-placement methods.The cited placement studies include implementations and optimization approaches for mobile networks.Source: §II · pp. 2–3

III. THREAT MODEL

  • The threat model assumes a functioning slice-operator network with supported slicing, virtualized network functions, and configurable slice VNFs.It also assumes slice-level authentication and user-defined functions are supported.Source: §III · p. 3, A. Assumptions · p. 3

A. Assumptions

  • The model further assumes component migration and operator-supported multi-tenancy, while bare-metal hardware configurations cannot be modified.Source: A. Assumptions · p. 3

B. Adversaries

The threat model considers external and administratively privileged adversaries in a multi-tenant network. It focuses on flooding attacks that can affect another slice through shared links and slice-initiated attacks that can affect co-hosted slices.

B. Adversaries

  • The model includes adversaries with administrative control of a slice and external attackers who may be slice users or outside entities.Source: B. Adversaries · p. 3

1) DDoS flooding attack:

  • For flooding attacks, an external adversary sends traffic that can flood a target slice’s communication links.Examples include UDP flooding and TCP SYN attacks.Source: 1) DDoS flooding attack · p. 3
  • A flood targeting slice #2’s authentication components can indirectly affect slice #1 when the slices share a physical core-network link.The example involves many IoT devices authenticating to slice #2.Source: 1) DDoS flooding attack · p. 3

2) Slice-initiated attack:

A slice with administrative control can initiate an attack by exhausting VNF resources, degrading co-hosted slices. The proposed solution allocates slices subject to isolation constraints, with physical and virtual network graphs representing topology and slice requests.

2) Slice-initiated attack:

  • A slice-initiated attack requires administrative privilege and can degrade other slices hosted on the same physical hosts by exhausting VNF resources.The described resource exhaustion includes sustained high CPU or RAM utilization.Source: 2) Slice-initiated attack · p. 3

IV. PROPOSED SOLUTION

  • The solution uses intra-slice isolation for reliability and availability, and inter-slice isolation to separate different slices.The optimization receives slice requests and isolation requirements, then produces an allocation scheme that is manually implemented.Source: §IV · pp. 3–4

V. OPTIMIZATION MODEL FORMULATION

  • Inter-slice isolation is modeled as complete hardware separation, preventing components from different slices from being allocated to the same host.The formulation considers one VNF per VM or container.Source: §V · p. 4

A. Network and Request Model

  • The model represents the physical core network as an undirected graph and each slice request as a directed graph of virtual functions and links.Requests are associated with delay and isolation requirements, while VNFs have computing demands and virtual links have bandwidth requirements.Source: A. Network and Request Model · p. 4

B. Objective function

The objective allocates slices to lightly utilized servers while minimizing path delay, subject to placement, resource, flow, and end-to-end delay constraints.

B. Objective function

  • The objective assigns slice requests to least-utilized physical servers and selects a minimum-delay path between slice components.It minimizes both terms of the objective function.Source: B. Objective function · p. 4

C. General Constraints

  • Constraints enforce one-server-per-VNF placement, physical CPU and bandwidth limits, whole-slice CPU availability, and flow conservation that ensures paths between VNFs.VNF allocations must fit physical capacities, and a slice’s CPU demand must fit the system’s remaining CPU capacity.Source: C. General Constraints · pp. 4–5
  • Constraint (9) guarantees each slice’s end-to-end delay, including link, VNF-processing, and physical-node-processing delay.Link delay depends on utilization, initial link delay, and the maximum increase; the values are calculated empirically.Source: C. General Constraints · p. 5

D. Security-related Constraints

The security constraints support different levels of intra-slice isolation and optional control- or data-plane separation between slices.

D. Security-related Constraints

  • Intra-slice isolation can separate control- and data-plane components, and may improve availability by limiting the effect of an attack on one component.With isolation, an operator may need to migrate only affected components, potentially enabling faster recovery than migrating the whole slice.Source: D. Security-related Constraints · p. 5
  • Inter-slice hardware isolation can be selected separately for control- and data-plane functions through γc and γd, respectively.Isolation is provided for a plane only when its corresponding parameter equals 1.Source: D. Security-related Constraints · p. 5
  • The proposed inter-slice isolation does not provide bandwidth isolation.Source: D. Security-related Constraints · p. 5

VI. EVALUATION AND EXPERIMENTAL SETUP

The evaluation combines a testbed with generic hardware and open-source tools because complete 5G slicing evaluation is challenging with available infrastructure.

VI. EVALUATION AND EXPERIMENTAL SETUP

  • Complete 5G network implementation and fine-grained slicing evaluation remain challenging, with few testbeds, no known public complete 5G RAN/core slicing simulator or emulator, and costly hardware and software.The authors therefore used available open-source tools and generic hardware.Source: §VI · p. 5

A. Experiment Setup

  • The testbed used six physical servers—three slice-allocation servers, two DDoS nodes, and one client—and deployed 12 statically allocated core-network slices with three components each.AMPL modeled the optimization, CPLEX 12.8.0 solved the MILP, and OpenVZ hosted VNFs in containers.Source: A. Experiment Setup · p. 5

B. Combining simulations with the use of testbed

The evaluation generates traffic traces in simulation and replays them in the testbed for DDoS experiments. A test authentication application measures the effects on slice performance.

B. Combining simulations with the use of testbed

  • The evaluation first simulates 320 mobile nodes sending UDP traffic and collects slice-destined traces at node C, then replays the traces at A1 and A2 for approximately 200 Mb/s DDoS attacks.Source: B. Combining simulations with the use… · pp. 5–6
  • The two-stage approach addresses scaling overhead that made it infeasible to combine large UE-generated traffic with the emulated PGW link during DDoS tests.The collected traces are replayed at the attack nodes instead.Source: B. Combining simulations with the use… · p. 6

C. Test Application

  • The test application uses a basic authentication protocol; its SEAF, AUSF, and HSS describe core functions but are not complete 5G-function implementations.The HSS database contains 1,000 records and uses binary search.Source: C. Test Application · p. 6
  • Authentication requests pass from client to SEAF, AUSF, and HSS, with responses returning through AUSF and SEAF to the client.Source: C. Test Application · p. 6

D. Evaluation Methodology

The evaluation measures authentication response time, client-to-slice RTT, and available bandwidth under flooding and CPU-load scenarios. Its comparisons use greedy allocation as a no-isolation baseline, with an important testbed-specific overlap between isolation levels.

D. Evaluation Methodology

  • The evaluation measures client response time, client-to-S1 RTT, and slice bandwidth while S4 is attacked and S1 provides authentication.Bandwidth is measured between the client and S1 and among S1’s virtual network functions.Source: D. Evaluation Methodology · p. 6
  • Baseline network RTT estimates Tef,init; RTT under approximately 100% link utilization estimates δ.Both estimates average measurements between the client and S1 components and among S1 components.Source: D. Evaluation Methodology · p. 7

VII. RESULTS AND DISCUSSION

  • Greedy first-come-first-served allocation defines NoIsolation, while Krel=1, 2, and 3 represent increasing intra-slice isolation levels.Each Krel experiment is repeated three times, with a new optimization solution and slice reallocation for each level.Source: §VII · p. 7
  • In the three-server testbed, Krel=3 coincidentally placed S1 and S4 on separate servers, so its results also include inter-slice isolation.The reported runs use γc=0 or γd=0; unpresented runs setting γc=1 or γd=1 differed by approximately 1–2% from Krel=3 results.Source: §VII · p. 7

A. DDoS flooding attack

Under flooding and slice-initiated CPU attacks, isolation reduces the measured impact on S1 relative to NoIsolation. The flooding results include response time, RTT, and available bandwidth; the CPU-load results show minimal impact across isolation levels.

A. DDoS flooding attack

  • NoIsolation produces very high client response time during flooding, while Krel=3 is lowest and Krel=1 and Krel=2 substantially reduce the impact.The authors attribute improvement partly to fewer kernel queues: at least six for NoIsolation, versus two for Krel=1 and three for Krel=2.Source: A. DDoS flooding attack · p. 7
  • Isolation improves client-to-S1 RTT at every Krel level versus NoIsolation, although RTT is lower than end-to-end authentication response time.RTT covers only client-to-SEAF traffic; authentication traverses three nodes.Source: A. DDoS flooding attack · p. 8, Figure 6 · p. 8
  • Against S1’s allocated 10Mb/s, available bandwidth falls below 1Mb/s under NoIsolation, while isolation preserves a high percentage of the allocation.The authors connect the bandwidth drop to the high response time and RTT.Source: A. DDoS flooding attack · p. 8, Figure 7 · p. 8

B. Slice-initiated attack

  • During slice-initiated CPU overload, NoIsolation has relatively high client response time, while all Krel isolation levels show minimal impact.Small response-time differences among Krel levels may reflect host and virtualization factors.Source: B. Slice-initiated attack · p. 8, Figure 8 · p. 8
  • CPU bottleneck has minimal RTT impact at all Krel levels, though CPU-intensive applications on other hosted slices could worsen the attack’s impact.RTT varies more than in the NoIsolation comparison, which the authors suggest may reflect changing CPU load when Ping requests arrive.Source: B. Slice-initiated attack · pp. 8–9, Figure 9 · p. 9

C. Current Limitations

The evaluation reports mitigation results for slice authentication and identifies allocation and testbed constraints. Complete isolation performed best in both attack scenarios, while intra-slice isolation offered a resource-utilization trade-off.

C. Current Limitations

  • The allocation scheme is static, lacks VNF migration, and omits processing delay from intermediate nodes.A worst case arises when many high-bandwidth or CPU-intensive VNFs from different slices share hosts and peak together during an attack.Source: C. Current Limitations · p. 9

VIII. CONCLUSION

  • Complete slice isolation provided the best mitigation in both attack scenarios; intra-slice isolation reduced response time and round-trip time versus NoIsolation.With no isolation, average available bandwidth was a fraction of requested bandwidth during DDoS; with the solution enabled, its impact was minimal.Source: §VIII · p. 9
  • Inter-slice isolation provides strong resource isolation but can reduce utilization efficiency; intra-slice isolation better controls the security, availability, and utilization trade-off.Source: §VIII · p. 9
  • The experiments used a small testbed; the authors plan to scale testing to check whether results hold on larger testbeds.Source: §VIII · p. 9
Loading 1901.01443v2…