Securing Local-Area Networks in AI Supercomputing Data Centers

1. Introduction

AI training and large-scale inference turn the data-center local-area network into part of the trusted computing base. Modern foundation-model workloads are not isolated calculations performed on a single server. A distributed job may read petabyte-scale datasets from shared storage, obtain credentials from an orchestration service, exchange gradients or activations among hundreds or thousands of accelerators, write periodic checkpoints, and publish a model or container image to a registry. Each transition crosses a network boundary and changes the set of principals that can influence the computation. Confidentiality, integrity, and availability therefore depend on switches, network interface cards, data-processing units (DPUs), baseboard management controllers (BMCs), fabric managers, schedulers, registries, and storage systems—not only on the operating system of a compute node.

The concentration of valuable assets makes this environment an unusually consequential security target. Training corpora may contain regulated or proprietary information; checkpoints and model weights can embody substantial financial and intellectual-property value; orchestration systems hold credentials capable of controlling large fleets; and high-speed east–west paths can move stolen data or malicious code much faster than conventional enterprise monitoring systems are designed to observe. Availability is equally important. A selective delay, route change, or storage disruption that would be a minor incident on an office LAN can stall a tightly synchronized training job, waste an expensive accelerator allocation, or invalidate hours of progress. LAN security in this setting must consequently protect the correctness and continuity of the AI workload, not merely prevent unauthorized Internet access.

Current reference architectures make the multi-fabric nature of the problem explicit. NVIDIA’s DGX SuperPOD H100 design identifies four distinct networks: compute, storage, in-band management, and out-of-band management [1]. Newer designs retain these functional roles while adopting routed leaf–spine Ethernet, EVPN/VXLAN overlays, BlueField DPUs, and RoCEv2 for high-performance storage [2]. The compute fabric optimizes collective communication, the storage fabric supplies sustained parallel I/O, the in-band network carries provisioning and service traffic, and the out-of-band network provides privileged lifecycle and recovery access. Separation improves performance, fault containment, and operational clarity, but it also creates multiple policy domains whose routing, identity, cryptographic, and logging decisions must remain consistent during provisioning, scaling, failure, and incident response.

These systems differ from conventional enterprise LANs in both mechanism and consequence. InfiniBand partitions and overlay identifiers can reduce reachability without cryptographically authenticating the workload that uses them. RDMA and one-sided communication intentionally bypass portions of the remote operating-system data path, weakening controls and audit assumptions that depend on host mediation [3,4,5]. BMCs operate below the host operating system and may retain control even when the host is rebuilt [6]. DPUs can move enforcement outside a compromised host, but they also introduce another firmware stack, management channel, and root of trust. Moreover, homogeneous cluster nodes, centralized schedulers, and automated provisioning amplify both defensive configuration changes and attacker-induced mistakes across a large population.

The central design challenge is therefore policy coordination across planes. Traditional segmentation answers which addresses or ports can communicate, whereas a zero-trust design asks which authenticated user, device, service, workload, and dataset should participate in a particular operation [7,8]. In an AI cluster, the answer is highly dynamic: a job may be entitled to a dataset and a set of peers only for the duration of one scheduler allocation, while an administrator may require temporary BMC access solely for a recovery task. Network authorization, service credentials, fabric partitions, storage permissions, and telemetry context should be created from the same approved intent and revoked together. Otherwise, stale privileges and inconsistent controllers can leave access paths open after the corresponding workload or maintenance action has ended.

Prior guidance addresses important parts of this problem, but the evidence is fragmented. Cybersecurity frameworks describe governance, zero trust, logging, incident response, and firmware resilience; vendor documents specify the topology and operational controls of AI-supercomputing platforms; and systems-security research exposes weaknesses in BMCs, RDMA, and software supply chains. These sources use different threat models and performance assumptions, making a direct comparison difficult. This survey connects them through a cross-plane systems view in which the security unit is the complete AI workload lifecycle—from data ingestion and artifact preparation through training, checkpointing, publication, and recovery.

The analysis considers external attackers who gain a foothold in a service network, malicious or compromised tenants, compromised compute hosts, management-plane insiders, and adversaries able to manipulate traffic or control-plane state. Network devices and controllers are not assumed to remain trustworthy after credential or firmware compromise. Physical attacks and wide-area inter-data-center links are outside the primary scope, although the proposed controls emphasize independent recovery paths because logical compromise can make normal administrative channels unavailable.

This paper addresses three research questions: (1) Which LAN and fabric threats are most consequential in AI supercomputing data centers? (2) Which controls are mature enough for deployment today? (3) Which performance–security tensions remain open research problems? It makes four contributions:

• It defines a multi-plane architecture and trust-zone model spanning out-of-band management, in-band services, storage, and high-performance compute fabrics.
• It synthesizes LAN, BMC, RDMA, AI-asset, and supply-chain threats into a common confidentiality, integrity, availability, and resilience analysis.
• It distinguishes deployment-ready controls from residual research gaps and proposes that short-lived workload identity drive network, fabric, and data authorization.
• It presents an evaluation framework that measures security effectiveness together with job completion, accelerator utilization, policy convergence, and recovery cost.

The remainder of the paper first defines the survey scope and method, then analyzes network architecture and the threat landscape. It next compares the available control families, develops the cross-plane synthesis and open research agenda, and concludes with an evaluation framework for testing proposed mechanisms under realistic AI communication and failure conditions.

2. Scope and Survey Method

The term LAN is used operationally to include the local Ethernet networks and switched high-performance fabrics inside an AI data-center site. The survey covers Ethernet management and service networks, InfiniBand, RoCEv2, storage fabrics, DPUs/SmartNICs, and BMC access. It excludes wide-area inter-data-center links, physical facility protection, and model-level adversarial examples except where network compromise can enable data poisoning, model theft, or workload manipulation.

A structured narrative method was used. Sources were selected from four evidence groups: cybersecurity and AI-risk standards; government hardening guidance; current AI-supercomputer architecture documentation; and peer-reviewed systems-security research. Priority was given to primary and authoritative material, including NIST, CISA, IEEE, IETF, DMTF, TCG, NVIDIA, MITRE, CIS, ACM, and USENIX publications. The peer-reviewed corpus was broadened with work from SC, IEEE IPDPS, IEEE Cluster, and IEEE/ACM CCGrid to connect security requirements with established results on topology, one-sided communication, accelerator networking, congestion, and RDMA-backed services. The final corpus contains 44 sources spanning foundational BMC research and high-performance interconnect studies through standards and architectures available in August 2026. Because implementations and threat reports are heterogeneous, this is a design-oriented survey rather than a statistical meta-analysis.

• Architecture lens: identify trust zones, control points, and inter-zone dependencies.
• Threat lens: map compromise paths to confidentiality, integrity, availability, and AI-asset impact.
• Control lens: distinguish deployment-ready safeguards from mechanisms requiring further research.

3. Network Architecture and Trust Zones

A secure design begins by separating traffic according to privilege and failure impact. A flat network lets a compromised worker discover management services, reach storage, or interfere with neighboring jobs. By contrast, a zoned design makes every crossing an explicit policy decision. CISA recommends physically separate out-of-band management, default-deny access control, dedicated administrative workstations, strong segmentation, and centralized protected logging [9]. NIST zero trust further rejects network location as a sufficient basis for trust [7].

Table 1. Security characteristics of major AI data-center network planes.

Plane	Typical components	Primary security objective	Representative controls
Out-of-band management	BMCs, switch consoles, DPU control, recovery hosts	Preserve privileged control and recovery even during production compromise	Physical/logical isolation; dedicated admin hosts; phishing-resistant MFA; Redfish over HTTPS; restricted egress
In-band services	Slurm/Kubernetes, provisioning, registries, DNS/NTP, user entry	Prevent service compromise from becoming cluster-wide control	Workload identity; microsegmentation; signed artifacts; mutual authentication; least privilege
Storage	Parallel file systems, object stores, NFS, checkpoint and model repositories	Protect dataset/model confidentiality, integrity, provenance, and availability	Encryption; dataset and artifact ACLs; immutable snapshots; integrity manifests; exfiltration monitoring
Compute fabric	GPU nodes, InfiniBand, RoCEv2, collective communication	Isolate jobs while sustaining deterministic low latency and high throughput	P_Key/VRF/VXLAN partitions; admission control; DPU enforcement; rate limits; fabric telemetry

Source: author synthesis based on [1,2,7,9,10].

Table 1. Security characteristics of major AI data-center network planes.

Plane	Typical components	Primary security objective	Representative controls
Out-of-band management	BMCs, switch consoles, DPU control, recovery hosts	Preserve privileged control and recovery even during production compromise	Physical/logical isolation; dedicated admin hosts; phishing-resistant MFA; Redfish over HTTPS; restricted egress
In-band services	Slurm/Kubernetes, provisioning, registries, DNS/NTP, user entry	Prevent service compromise from becoming cluster-wide control	Workload identity; microsegmentation; signed artifacts; mutual authentication; least privilege
Storage	Parallel file systems, object stores, NFS, checkpoint and model repositories	Protect dataset/model confidentiality, integrity, provenance, and availability	Encryption; dataset and artifact ACLs; immutable snapshots; integrity manifests; exfiltration monitoring
Compute fabric	GPU nodes, InfiniBand, RoCEv2, collective communication	Isolate jobs while sustaining deterministic low latency and high throughput	P_Key/VRF/VXLAN partitions; admission control; DPU enforcement; rate limits; fabric telemetry

Source: author synthesis based on [1,2,7,9,10].

Figure 1. A cross-plane security model for AI-supercomputing LANs. A layered security architecture with an identity, policy, and telemetry plane above four protected zones: out-of-band management, in-band services, storage, and the compute fabric. Arrows show controlled dependencies from management to services, storage, and compute.

Figure 1. A cross-plane security model for AI-supercomputing LANs. A layered security architecture with an identity, policy, and telemetry plane above four protected zones: out-of-band management, in-band services, storage, and the compute fabric. Arrows show controlled dependencies from management to services, storage, and compute.

3.1. Ethernet Overlays and Routed Fabrics

Modern AI data centers increasingly use routed leaf-spine Ethernet with eBGP underlays and EVPN/VXLAN overlays. VXLAN supplies Layer-2 overlay encapsulation over an IP underlay, while EVPN supplies control-plane procedures for network-virtualization overlays [11,12]. Routing reduces broadcast-domain scope and overlays provide logical separation, while multihoming and equal-cost multipath improve availability. Those benefits do not automatically establish trust: a VNI identifies a segment but does not authenticate a workload or encrypt its traffic. Route policy, overlay identifiers, controller credentials, and DPU configuration therefore become high-value control-plane assets. Misconfiguration can create unintended reachability even when the physical topology is sound [2].

3.2. InfiniBand and RDMA

InfiniBand partitions use a 16-bit Partition Key (P_Key) that is checked by adapters and switches; the subnet manager programs membership [13]. This is a useful isolation primitive, but the value is an identifier rather than a cryptographic secret. Supercomputing research shows why these fabrics remain attractive: low-diameter topologies reduce latency and cost, while InfiniBand, one-sided MPI, and GPUDirect RDMA can sustain highly scalable communication with limited host intervention [14,15,16,17]. RoCEv2 carries RDMA semantics over routed Ethernet and inherits both Ethernet/IP control-plane risks and RDMA authorization concerns. Consequently, fabric isolation should be combined with strong endpoint admission, protected fabric management, host hardening, and cryptographic protection where the threat model includes malicious insiders or compromised nodes.

4. Threat Landscape

4.1. Local Network and Control-Plane Attacks

Traditional LAN attacks remain relevant: unauthorized attachment, address spoofing, rogue DHCP or router advertisements, ARP/neighbor discovery manipulation, VLAN or overlay misconfiguration, control-plane denial of service, and route-policy abuse. A compromised switch, fabric manager, or software-defined networking controller can alter reachability at scale. MITRE ATT&CK describes service discovery and exploitation of remote services as common enablers of lateral movement [18]. Containerized schedulers and service platforms add exposed APIs, image and runtime risks, and east-west service dependencies; NIST container guidance and the NSA/CISA Kubernetes hardening guide recommend reducing administrative exposure, enforcing least privilege, and protecting cluster components [19,20]. AI clusters magnify the impact because nodes are homogeneous, management tools are highly privileged, and high-bandwidth east-west paths can accelerate both propagation and data exfiltration.

4.2. Management-Plane and BMC Compromise

BMCs operate below the host operating system and can control power, virtual media, console access, and firmware. Early empirical work showed that vulnerable IPMI implementations could permit remote control of the BMC and potentially the host [6]. The architectural lesson remains current: the management LAN is not a convenience network; it is a privileged recovery system. If it shares credentials, routing, or administrative endpoints with production, an attacker may disable evidence, persist below the operating system, or block recovery. Redfish modernizes management interfaces and requires HTTPS for session creation, but secure deployment still depends on certificate validation, account lifecycle, session controls, patching, and network isolation [21].

4.3. One-Sided Communication and RDMA Abuse

RDMA improves latency and CPU efficiency by allowing network hardware to access remote memory with little or no remote CPU participation. SC and IPDPS results demonstrate that one-sided operations and lease-based RDMA services can scale to demanding HPC workloads, making host bypass a deliberate performance feature rather than an implementation accident [15,22]. That same property can bypass controls that assume the receiving operating system will inspect each operation. Research has demonstrated unauthorized memory access, impersonation, packet injection, connection disruption, and denial of service against RDMA environments [3]. sRDMA argues that capability tokens transmitted without authentication or encryption are weak against in-network and compromised-host adversaries [4]. One-sided I/O also complicates accountability because malicious reads and writes may not generate conventional host-level events [5].

Figure 2. Comparison of a conventional socket path with one-sided RDMA. The remote CPU can participate in policy enforcement and audit on a conventional receive path, whereas one-sided RDMA can access registered memory without per-operation remote CPU mediation. Two horizontal communication paths are compared. The conventional socket path traverses sender and receiver kernels, while the one-sided RDMA path traverses local and remote network interface cards directly to registered memory.

Figure 2. Comparison of a conventional socket path with one-sided RDMA. The remote CPU can participate in policy enforcement and audit on a conventional receive path, whereas one-sided RDMA can access registered memory without per-operation remote CPU mediation. Two horizontal communication paths are compared. The conventional socket path traverses sender and receiver kernels, while the one-sided RDMA path traverses local and remote network interface cards directly to registered memory.

4.4. Ai-Specific Asset Pathways

Network compromise can become an AI integrity or confidentiality incident. Unauthorized storage access can alter training data, replace checkpoints, steal model weights, or expose prompts and evaluation corpora. RDMA-enabled GPU communication and object storage shorten these data paths and reduce CPU mediation, as demonstrated by Cluster and CCGrid systems work [17,23]. Compromise of a scheduler, image registry, package mirror, or continuous-integration system can distribute malicious code to many nodes. NIST’s adversarial machine-learning taxonomy notes that AI outcomes depend both on model vulnerabilities and on weaknesses in the supporting infrastructure [24]. SSDF, SLSA, in-toto, and Sigstore provide complementary practices for secure development, verifiable build provenance, supply-chain layout verification, and identity-linked artifact signing [25,26]. Network controls should therefore protect lineage and authorization transitions across ingestion, build, training, evaluation, registry publication, and inference - not merely protect an inference API.

Figure 3. Security-relevant stages and transitions in the AI workload lifecycle. Identity, authorization, integrity, provenance, and telemetry must remain consistent as data and artifacts move from ingestion through deployment. A lifecycle diagram follows AI data and artifacts through ingestion, preparation, training, checkpointing, evaluation, publication, and inference, with security controls spanning the transitions.

Figure 3. Security-relevant stages and transitions in the AI workload lifecycle. Identity, authorization, integrity, provenance, and telemetry must remain consistent as data and artifacts move from ingestion through deployment. A lifecycle diagram follows AI data and artifacts through ingestion, preparation, training, checkpointing, evaluation, publication, and inference, with security controls spanning the transitions.

4.5. Availability and Cascading Failure

Large synchronous training jobs are sensitive to stragglers, packet loss, congestion, and node failure. InfiniBand multipathing and newer Dragonfly routing studies show that path selection and hotspot avoidance materially affect application-visible performance [27,28,29]. An attacker may not need to saturate the entire fabric; selectively delaying collective communication or disrupting storage metadata can waste an expensive allocation and invalidate checkpoints. Defensive actions can also cause damage: abruptly quarantining one node may stall a tightly coupled job. Availability protection must coordinate network containment with the scheduler, checkpoint manager, and recovery workflow.

5. Security Control Landscape

5.1. Governance, Inventory, and Architecture

NIST CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover [30]. For an AI cluster, governance should define owners for every fabric and controller, classify datasets and models, set availability objectives for training and inference, and establish change approval for routing, partitions, firmware, and orchestration. Accurate inventories must include switches, optics, NICs, DPUs, BMCs, firmware, fabric managers, service accounts, certificates, and logical overlays. CIS Controls 12 and 13 reinforce active network infrastructure management and comprehensive monitoring [10].

5.2. Segmentation and Zero-Trust Access

Segmentation should separate OOB management, in-band services, storage, compute, user access, tenant workloads, and security tooling. Default-deny policy should be enforced at more than one layer: routed ACLs or firewalls, VRFs/VXLAN segments, DPU or host policy, and application authorization. NIST zero trust requires authentication and authorization based on identity and context rather than location alone [7]; SP 800-207A extends that model to service identities and granular application-tier policy [8]. CISA’s Zero Trust Maturity Model similarly organizes progress across identity, devices, networks, applications and workloads, and data [31]. In practice, a job’s network entitlements should be derived from scheduler-approved membership, limited to required peers and services, and revoked when the job completes. Break-glass recovery identities should be separate from daily administrative identities.

5.3. Identity, Device Admission, and Administration

Administrative access should originate only from dedicated, hardened workstations through the isolated OOB path. Central AAA, phishing-resistant MFA, role-based access control, short sessions, and command/configuration logging reduce the risk of shared or persistent privilege [9]. Device admission can use IEEE 802.1X port-based access control and IEEE 802.1AR device identifiers, with certificate rotation and locally controlled enrollment [32,33]. Admission decisions can additionally consume measured-state evidence: SPDM authenticates components, TPM and DICE specifications provide roots and evidence for measured identity, and the IETF RATS architecture separates attesters, verifiers, and relying parties [34,35]. Workload identity should be bound to the scheduler or orchestrator rather than to long-lived node IP addresses. The policy engine must fail safely when identity, attestation, certificate status, or controller connectivity is unavailable.

5.4. Data-Plane Protection

MACsec provides confidentiality, integrity, and origin authenticity for Ethernet frames [36]. TLS 1.3 protects client/server application traffic from eavesdropping, tampering, and forgery [37]. IPsec can protect routed flows through IP-layer security associations and policy databases [38], while application-layer encryption can remain end to end across overlay boundaries. The correct choice depends on trust boundaries and performance budgets. Link encryption protects a cable or adjacent segment but terminates at each secured hop; end-to-end protocols provide stronger path coverage but may add key-management, CPU, DPU, or observability costs. Encryption should not be treated as a substitute for authorization or segmentation.

Figure 4. Scheduler-driven, job-scoped authorization. A short-lived workload identity coordinates compute membership, fabric policy, data access, telemetry context, and revocation at job completion. A sequence diagram shows a user submitting a job, the scheduler obtaining workload identity and policy, enforcement across compute, network, and storage resources, and coordinated revocation when the job ends.

Figure 4. Scheduler-driven, job-scoped authorization. A short-lived workload identity coordinates compute membership, fabric policy, data access, telemetry context, and revocation at job completion. A sequence diagram shows a user submitting a job, the scheduler obtaining workload identity and policy, enforcement across compute, network, and storage resources, and coordinated revocation when the job ends.

5.5. High-Performance Fabric Controls

InfiniBand deployments should restrict and harden the subnet manager, use partitions, protect management and administration keys, disable unnecessary defaults, and monitor partition changes [13]. RoCE deployments should combine Ethernet admission and segmentation with RDMA-aware access control and congestion protection. DPUs can enforce policy before traffic reaches a potentially compromised host; NVIDIA’s restricted or zero-trust DPU mode can prevent the host administrator from controlling the DPU [39]. This moves enforcement into a separate domain, but it also enlarges the trusted computing base to include DPU firmware, management software, and update channels.

5.6. Monitoring, Detection, and Response

Useful telemetry includes authenticated configuration changes, administrator and service logins, route and overlay updates, partition membership, flow records, denied connections, RDMA errors, congestion signals, DPU events, storage access, checkpoint integrity, and scheduler state. Logs should be centrally protected, normalized, retained, and copied outside the failure domain, consistent with CISA and NIST log-management guidance [9,40]. Detection must join network context with workload semantics: a high-volume flow may be normal for collective communication but suspicious if it connects a training job to an unapproved storage or egress destination. Response playbooks should support graduated controls such as rate limiting, credential revocation, path isolation, safe checkpointing, node quarantine, and full fabric containment; NIST SP 800-61 Rev. 3 emphasizes integrating these response and recovery capabilities into broader risk management [41].

Figure 5. Security-aware containment workflow for tightly coupled AI jobs. Graduated response permits evidence collection and safe checkpointing when conditions allow, while active harm triggers immediate isolation and rebuild. A branching incident-response flow moves from normal operation to a suspected incident and rate limiting, then either safe checkpointing and quarantine or immediate isolation and rebuild, followed by validated recovery.

Figure 5. Security-aware containment workflow for tightly coupled AI jobs. Graduated response permits evidence collection and safe checkpointing when conditions allow, while active harm triggers immediate isolation and rebuild. A branching incident-response flow moves from normal operation to a suspected incident and rate limiting, then either safe checkpointing and quarantine or immediate isolation and rebuild, followed by validated recovery.

5.7. Firmware, Supply Chain, and Recovery

Switches, NICs, DPUs, BMCs, and accelerators depend on signed firmware and trustworthy boot chains. NIST SP 800-193 frames firmware resilience as protection, detection, and secure recovery from unauthorized changes [42]. NIST supply-chain guidance further calls for risk assessment across acquired products and services, while SSDF and SLSA extend assurance to development and build provenance [25,43,44]. SPDM, TPM, and DICE can provide component authentication and measured-state evidence, but their value depends on verifier policy, endorsement lifecycle, freshness, and secure recovery of trust anchors [34,35]. Operators should verify images, control update sources, test rollback and recovery, track component provenance, and maintain offline configuration backups. Recovery should be demonstrable without relying on the production identity provider or the fabric under investigation.

Table 2. Threat-control synthesis and residual gaps

Threat class	Likely impact	Deployment-ready controls	Residual research gap
Unauthorized attachment or lateral movement	Cluster service compromise; data/model access	Device admission; default-deny segmentation; workload identity; service allow lists	Fast, verifiable policy changes synchronized with scheduler state
BMC or management-plane takeover	Persistent privileged control; evidence destruction; blocked recovery	Physically separate OOB; dedicated admin hosts; MFA; HTTPS; signed firmware; protected logs	Measurable independence of recovery planes and identity systems
RDMA/one-sided abuse	Unauthorized memory access; impersonation; DoS	Fabric partitions; endpoint hardening; DPU enforcement; rate controls	Cryptographic, revocable RDMA capabilities at accelerator-fabric speed
Route/overlay/controller compromise	Unintended reachability; interception; large-scale outage	Authenticated management; configuration source of truth; change alerts; control-plane protection	Formal verification and safe rollback for multi-controller fabrics
Dataset/checkpoint/model tampering	Poisoned training; corrupted output; IP loss	Artifact signing; integrity manifests; provenance; storage ACLs; immutable snapshots	End-to-end binding of data lineage, job identity, and network flows
Selective congestion or disruption	Training stall; wasted allocation; incomplete recovery	QoS; anomaly detection; redundant paths; checkpoint strategy	Security-aware collectives and containment that preserve job progress

Table 2. Threat-control synthesis and residual gaps

Threat class	Likely impact	Deployment-ready controls	Residual research gap
Unauthorized attachment or lateral movement	Cluster service compromise; data/model access	Device admission; default-deny segmentation; workload identity; service allow lists	Fast, verifiable policy changes synchronized with scheduler state
BMC or management-plane takeover	Persistent privileged control; evidence destruction; blocked recovery	Physically separate OOB; dedicated admin hosts; MFA; HTTPS; signed firmware; protected logs	Measurable independence of recovery planes and identity systems
RDMA/one-sided abuse	Unauthorized memory access; impersonation; DoS	Fabric partitions; endpoint hardening; DPU enforcement; rate controls	Cryptographic, revocable RDMA capabilities at accelerator-fabric speed
Route/overlay/controller compromise	Unintended reachability; interception; large-scale outage	Authenticated management; configuration source of truth; change alerts; control-plane protection	Formal verification and safe rollback for multi-controller fabrics
Dataset/checkpoint/model tampering	Poisoned training; corrupted output; IP loss	Artifact signing; integrity manifests; provenance; storage ACLs; immutable snapshots	End-to-end binding of data lineage, job identity, and network flows
Selective congestion or disruption	Training stall; wasted allocation; incomplete recovery	QoS; anomaly detection; redundant paths; checkpoint strategy	Security-aware collectives and containment that preserve job progress

6. Comparative Synthesis and Design Trade-Offs

The reviewed controls are complementary rather than interchangeable. VLANs, VRFs, VXLANs, and P_Keys reduce reachability but do not by themselves authenticate a workload or encrypt its traffic. MACsec protects Ethernet links but does not express job-level authorization. TLS can protect an application session but cannot prevent a compromised scheduler from issuing valid credentials. A DPU can isolate a host, yet a vulnerable DPU management plane can become a new concentration of privilege. Zero trust supplies the decision model, while segmentation, cryptography, hardware roots of trust, and telemetry supply enforcement and evidence.

Three trade-offs recur. First, visibility competes with encryption and line-rate performance; packet inspection may be infeasible or semantically weak on encrypted RDMA traffic. Second, availability competes with aggressive containment; isolation of one node can terminate a synchronized job. Third, automation reduces configuration drift but amplifies controller mistakes. Secure operation therefore requires staged rollout, intent validation, independent observation, bounded blast radius, and tested rollback.

7. Open Research Challenges

1.

Cross-plane identity and policy consistency. Develop a verifiable identity chain from user and code artifact to scheduler allocation, NIC/DPU policy, fabric partition, dataset entitlement, and checkpoint destination. The key problem is atomic revocation across systems with different control loops.

2.

Line-rate cryptography for accelerator fabrics. Quantify the latency, throughput, power, and failure effects of MACsec, IPsec, TLS, and DPU offload at 400/800 Gb/s and beyond, including collective communication and small-message workloads rather than bulk-transfer averages alone.

3.

Revocable and auditable RDMA authorization. Replace weak bearer-like access tokens with capabilities that are authenticated, least-privileged, rapidly revocable, replay-resistant, and observable without returning all I/O to the remote CPU.

4.

DPU and SmartNIC assurance. Measure whether moving enforcement off host actually reduces total risk. Research should cover firmware provenance, secure boot, isolation among services, formal verification, side channels, update failure, and administrator separation.

5.

AI-aware network detection. Fuse flow/fabric telemetry with scheduler, topology, data lineage, and model lifecycle context. Detection must differentiate normal all-to-all traffic from reconnaissance, selective degradation, exfiltration, or unauthorized storage access.

6.

Containment for tightly coupled jobs. Design responses that limit attacker movement while preserving safe checkpointing and avoiding cascading failure. Candidate approaches include traffic shaping, quorum-based isolation, shadow paths, and scheduler-coordinated quarantine.

7.

Security benchmarks and reproducible testbeds. Create representative open traces, attack scenarios, and metrics for Ethernet, RoCE, InfiniBand, DPUs, BMCs, and AI workloads. Useful metrics include time to detect, policy convergence, blast radius, job-completion loss, recovery time, and security energy cost.

8.

Resilience of management dependencies. Analyze correlated failures across AAA, PKI, DNS, NTP, automation, logging, and OOB networks. A recovery plane should remain usable during compromise of any one production dependency and should be tested as an end-to-end system.

8. Proposed Evaluation Framework

Future studies should evaluate security mechanisms under realistic AI communication patterns and fault scenarios. A useful experiment should state the adversary’s location (external, compromised service, malicious tenant, compromised host, or management insider), the fabrics reachable to that adversary, and whether network devices or controllers are trusted. Results should report security and operational metrics together.

Figure 6. Controlled evaluation framework for comparing network-only segmentation, workload-aware segmentation, and identity-plus-DPU enforcement under identical AI workloads and injected attacks or faults. Representative AI workloads and attack or fault injectors feed a controlled experiment harness. Three enforcement designs are compared using common security, performance, resilience, and operational metrics.

Figure 6. Controlled evaluation framework for comparing network-only segmentation, workload-aware segmentation, and identity-plus-DPU enforcement under identical AI workloads and injected attacks or faults. Representative AI workloads and attack or fault injectors feed a controlled experiment harness. Three enforcement designs are compared using common security, performance, resilience, and operational metrics.

• Security effectiveness: prevented actions, residual privilege, replay resistance, and cross-tenant isolation.
• Performance: job completion time, tail latency, collective bandwidth, storage throughput, and accelerator utilization.
• Detection: time to detect, false-positive rate, visibility under encryption, and attribution to a user/job/artifact.
• Resilience: policy convergence, recovery time, checkpoint loss, and behavior during controller or identity-provider failure.
• Operational cost: configuration complexity, key and certificate lifecycle, firmware-update burden, energy, and observability overhead.

One concrete study could compare three cluster designs: network-only segmentation, segmentation plus workload identity, and segmentation plus identity with DPU enforcement. ReDMArk-style hostile-host tests, route/overlay misconfiguration, credential compromise, and selective congestion could be injected while representative distributed training and checkpoint workloads run. The experiment would test whether deeper enforcement reduces blast radius without causing unacceptable job-completion loss.

9. Conclusions

LAN security in an AI supercomputing data center is a cross-layer systems problem. Established guidance converges on strong segmentation, isolated management, least privilege, phishing-resistant administration, encryption, protected telemetry, firmware resilience, and rehearsed recovery. Yet high-performance fabrics create gaps that conventional enterprise controls do not fully close. Isolation identifiers may not be cryptographic, one-sided I/O can bypass host mediation, and incident response can disrupt synchronized workloads. The most promising direction is to bind network authorization to short-lived workload identity and AI data provenance, enforce it across hosts and DPUs, and evaluate it with both security and job-level resilience metrics.