{"id":"d96a4943-dd61-4f61-ac88-1907b9f41083","arxiv_id":"2508.09663","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Container-granular, multi-tenant RDMA access to HPE Slingshot is implemented for Kubernetes through netns-based CXI services, a CNI plugin, and a VNI service, with overhead below 3.5%.","lead":"This paper extends HPE Slingshot, an HPC network interconnect, so Kubernetes containers can safely share it in multi-tenant cloud-HPC clusters. It adds network-namespace-based authentication, a CNI plugin, and a VNI management service, and measures overhead below 3.5%.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Netns-based authentication assumes network namespace IDs are unforgeable and non-reusable; both assumptions are unverified and can be violated.","rationale":"The reader's weakest_assumption correctly identifies the netns-based authentication as the load-bearing security mechanism. My analysis confirms and sharpens this concern: the paper's assertion that containers cannot modify their network namespace ID is too broad because CAP_SYS_ADMIN grants the ability to join other namespaces, and the paper provides no evidence that CAP_SYS_ADMIN is always unavailable in the target deployment. Additionally, the inode-reuse concern raised by the reader is valid and already hinted at by the paper's own caveat about CNI plugin unavailability during cleanup. These are correctness risks, not merely deviations from current consensus: if either failure mode is exploitable, the central 'secure, container-granular, multi-tenant access' claim is false. The performance evaluation is thorough and suggests no performance regression, but it does not test the security properties. Given that the paper is a systems contribution with a sound design in principle, conditional acceptance is appropriate: the authors should either close these gaps (e.g., bind CXI services to cgroup or pod identity, verify CAP_SYS_ADMIN restrictions, or add explicit limitations) or provide a security evaluation. The reader's verdict is therefore unchanged by this stress-test pass.","tokens_in":12308,"tokens_out":3355,"duration_ms":39727,"concrete_test":"Attempt a cross-tenant lookup/access attack: on a node, run a victim pod annotated with vni:true that creates an RDMA endpoint, and run an attacker pod in a different tenant whose securityContext grants CAP_SYS_ADMIN. From the attacker, call setns() to enter the victim's network namespace (using the victim PID and /proc/<pid>/ns/net) and then attempt to create a CXI endpoint on the victim's VNI via libcxi. If endpoint creation succeeds, the netns authentication is bypassable and the paper's security claim is refuted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that the extended Slingshot stack provides 'secure, container-granular, and multi-tenant access' rests on the netns member type introduced in Section III.A. The paper states that malicious users inside a container cannot modify their network namespace ID, but this ignores two concrete failure modes. First, any container with CAP_SYS_ADMIN can call unshare(CLONE_NEWNET) or setns() to enter another container's network namespace. For example, an attacker container that is privileged or has SYS_ADMIN added via its securityContext can join a victim container's netns and then request a CXI endpoint; authentication would succeed because the CXI driver sees the victim's netns inode. Second, Linux namespace inode numbers are not guaranteed to be globally unique over time; a destroyed network namespace's inode can be reused by a newly created one. The CNI plugin deletes CXI services on DEL, but the paper acknowledges in Section III.B that cleanup only happens if the plugin is available throughout the container lifetime. If a node fails or the CNI plugin is temporarily unavailable, a stale CXI service remains keyed to a freed inode. A subsequent container whose new netns reuses that inode would inherit the prior tenant's VNI and CXI service, breaking isolation. The evaluation in Section IV measures only performance overhead; no security experiment is presented. The claimed security property therefore depends on an unvalidated identity-binding assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents an extension of the HPE Slingshot RDMA software stack for multi-tenant Kubernetes deployments. The contributions are: (A) a new network-namespace (netns) member type for CXI services in the driver/libs, (B) a CNI plugin that creates and destroys CXI services for containers, and (C) a Kubernetes VNI Service that manages VNI allocation and lifetime via CRDs and a database. The evaluation reports RDMA communication overhead within 1% and job admission overhead of 3.5% (ramp) and 1.6% (spike) compared to a non-integrated Kubernetes baseline. The abstract claims the integration provides 'secure, container-granular, and multi-tenant access to Slingshot RDMA networking capabilities at minimal overhead.'","tokens_in":12615,"tokens_out":5120,"duration_ms":55301,"significance":"If the security claim were substantiated, this would be a valuable step toward converged HPC-cloud systems, since it addresses a real gap in the Slingshot access model. The performance evaluation is a clear strength: it uses standard OSU benchmarks, multiple runs, percentile intervals, and a plausible job-admission workload; the open-source release of code and measurement data further supports reproducibility. However, the central security assertion is not evaluated at all, and the design rests on an identity-binding assumption that is not established and is, in fact, questionable. The work is therefore only partially supported: the performance contribution is credible, but the security contribution needs substantial additional work before the stated central claim can be accepted.","major_comments":[{"comment":"The security of the netns-based CXI service authentication is load-bearing. The paper states that 'malicious users inside a container cannot modify their network namespace ID.' This conflates the immutability of an inode number with the ability of a process to change its network namespace. A container with CAP_SYS_ADMIN can call unshare(CLONE_NEWNET) or setns() and thereby present a different netns at endpoint-creation time. If an attacker can enter another tenant's netns, CXI authentication will succeed under the victim's membership. No threat model is given, and Section IV contains no security experiments. The 'secure, container-granular' claim needs either a restriction to containers without CAP_SYS_ADMIN, a mechanism that binds CXI services to a stronger identity, or an explicit security evaluation demonstrating that namespace switching is not possible in the target environment.","section":"Section III.A"},{"comment":"The lifecycle of CXI services is not safe under inode reuse or plugin unavailability. The manuscript itself acknowledges in Section III.B that automatic cleanup 'only occur[s] if the CXI CNI plugin is available throughout the lifetime of all Slingshot-enabled containers.' Linux netns inode numbers can be reused after the namespace is destroyed. If a stale CXI service remains keyed to a freed inode, a new container whose netns happens to reuse that inode can inherit the prior tenant's VNI and CXI service. The 30-second VNI release grace period in Section III.C does not address this case because the stale service is not tied to the VNI database record; it is tied only to the inode. This is a concrete isolation-breaking scenario, and it should be either fixed (e.g., by storing a generation counter or pod reference in the CXI service) or explicitly analyzed and tested.","section":"Section III.B, III.C"},{"comment":"The evaluation measures performance only. Figures 5-12 quantify throughput, latency, and admission delay, but there is no isolation or security evaluation whatsoever. Since the abstract's central claim is security, the absence of any adversarial test for namespace isolation, CXI service identity spoofing, or inode reuse is a major omission. Please add at least a threat model and a small set of experiments that attempt cross-tenant endpoint creation, namespace joining, and stale-service inheritance. Without such evidence, the paper's title and abstract overstate what is demonstrated.","section":"Section IV"}],"minor_comments":[{"comment":"Figure 8 caption says '25 iterations' while the text says the OSU benchmarks were run 10 times. Please align these numbers.","section":"Section IV.A"},{"comment":"The caption says 'green line shows the number of jobs launched per job'; this should read 'per batch.'","section":"Figure 9"},{"comment":"Reference [3] appears to contain a typo ('vDirect Direct Data Placement...'), and the formatting of 'V olcano' in Section IV.A should be fixed.","section":"References"},{"comment":"The description of retrieving the netns ID 'using procfs' is imprecise for a kernel driver; the driver should read the process's nsproxy directly. Clarify the mechanism.","section":"Section III.A"},{"comment":"The assumption that 'users are not allowed to create or modify VNI CRD instances directly' is an administrative security assumption. It should be stated explicitly as part of the threat model, since it is essential to the exclusivity of VNI allocation.","section":"Section III.C.1"}],"recommendation":"major_revision","confidential_remarks":"The performance work is solid and reproducible, but the central 'secure' claim is unsubstantiated and rests on an insecure or at least unverified identity-binding assumption. The paper would need either a security evaluation or a substantially narrowed claim to be acceptable. I would not recommend rejection because the integration and performance results are valuable and the security gap is addressable with additional experiments and caveats."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core contribution here is real: a netns-based member type for CXI services, plus a CNI plugin and VNI service integrated into Kubernetes. That is the first container-granular CXI service management I know of for Slingshot, and it is a sensible answer to the identity problem that UID/GID auth cannot solve in Kubernetes. The design is clean, the code and data are shipped, and the performance evaluation is honest and solid: OSU benchmarks with multiple runs and percentiles, communication overhead within noise, and admission overhead around 1–3.5%. The authors also state the cleanup limitation explicitly, which is more than many systems papers do.\n\nThe soft spot is the security claim. The paper says netns inodes cannot be modified by malicious users, and the stress-test note correctly points out two ways this fails. A container with CAP_SYS_ADMIN can call unshare() or setns() to join another namespace. And netns inode reuse after deletion can leave a stale CXI service and VNI attached to a freed inode, especially when the CNI plugin is unavailable during deletion—a case the paper itself acknowledges in Section III.B. None of this is tested. So the word \"secure\" in the abstract is doing more work than the evidence supports. This is not a minor nit; it is a load-bearing part of the central claim. That said, the design is not fundamentally broken. If the authors narrow the threat model (no privileged containers, operator guarantees plugin availability), or add a real security evaluation, the claim becomes defensible. As written, it is conditional.\n\nThis paper deserves a serious referee. It is a solid systems contribution with reproducible measurements, and the security gap is addressable in revision. The right outcome is likely conditional acceptance with a request for an explicit threat model and at least a sanity-check experiment on the netns assumptions. I would bring it to a reading group focused on HPC-cloud convergence or container networking.\n\nSerial: yes, cite it if I write about container networking for RDMA fabrics, but with a caveat about the security analysis. Recommend peer review over desk rejection.","headline":"A well-built engineering contribution to multi-tenant Slingshot RDMA in Kubernetes, but the paper's 'secure' claim rests on an untested netns-inode identity assumption.","tokens_in":13064,"tokens_out":1953,"would_cite":true,"duration_ms":22428,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper extends HPE Slingshot's RDMA stack so Kubernetes containers get secure, per-tenant network isolation at under 1% communication overhead and roughly 1.6–3.5% job admission overhead.","keywords":["HPE Slingshot","RDMA","Kubernetes","multi-tenant networking","network namespaces","CNI plugin","converged HPC-Cloud","virtual network isolation"],"falsifier":"Give a pod CAP_SYS_ADMIN and let it enter the network namespace of a neighbor pod, then attempt a Slingshot RDMA endpoint creation: if the CXI service for the neighbor's namespace admits it, the netns authentication is bypassable. A second test: delete a Slingshot-enabled pod, wait for its namespace inode to be recycled, create a new pod, and check whether its RDMA endpoint unexpectedly inherits the deleted pod's VNI and can see its traffic.","tokens_in":12226,"feed_emoji":"🌐","tokens_out":10724,"duration_ms":87820,"temperature":0.7,"pith_summary":"Converged HPC-Cloud systems want both cloud-style tenant isolation and HPC-grade communication speed, and HPE Slingshot — the 200 Gbps RDMA interconnect used in leading supercomputers — was built for only one of those: its access control authenticates users by Linux UID/GID, an identity that means nothing in Kubernetes, where every container runs under a single cluster-wide user. The paper claims to close this gap with a three-layer extension to the Slingshot stack: a driver and library change that authenticates RDMA endpoint creation by network namespace instead of user ID, a CNI plugin that creates and destroys per-container access services, and a VNI Service that manages Slingshot Virtual Networks as Kubernetes custom resources. On an evaluation cluster, the integration shows under 1% overhead in RDMA throughput and latency and 1.6–3.5% overhead in job admission time. If these numbers hold, converged clusters can co-locate mutually isolated tenants on a shared high-speed fabric without sacrificing RDMA performance.","feed_headline":"Kubernetes pods get isolated Slingshot RDMA at under 1% overhead","feed_subtitle":"Each pod authenticates to the network by namespace, not user ID, so co-located tenants stay isolated at full speed.","key_machinery":"The load-bearing mechanism is the netns CXI service member type: a third membership class in the Slingshot access model that identifies authorized users by their network namespace inode, read from procfs, instead of by Linux UID/GID. Kubernetes runs every container under one UID, so only a per-container kernel identity such as the network namespace can serve as a tenant principal; the netns check happens once, at RDMA endpoint creation, and preserves kernel-bypass afterwards. Two further components carry that identity through the cluster: the CXI CNI plugin, which creates and deletes per-container CXI services, and the VNI Service, whose controller and database expose Virtual Network IDs as","core_discovery":"On the paper's own terms, the core claim is that container-granular RDMA isolation can be layered onto Slingshot by changing the identity that grants access. A new netns member type in the CXI driver stores a container's network namespace inode; at endpoint creation the extended driver reads the caller's namespace ID from procfs and admits the endpoint only on a match. A CNI plugin creates one CXI service per container on ADD and removes it on DEL, and a VNI Service allocates Virtual Network IDs through a database-backed Kubernetes controller with two ownership models: one VNI per job, or one shared VNI per claim. The evaluation puts the cost at under 1% in throughput and latency and 1.6–3.5","pith_inferences":["Editorial extension: the netns-isolation guarantee presumes a container cannot change its namespace identity; a pod granted CAP_SYS_ADMIN can create or enter namespaces, which would let it authenticate as another tenant — a case the paper states but does not test.","Editorial extension: network-namespace inodes are recycled by the kernel after deletion, so a new container could inherit the inode — and with it any stale CXI service and VNI — of a departed tenant if the CNI plugin's DEL path fails or the 30-second VNI-release window is violated.","Editorial extension: the netns-as-principal pattern is not Slingshot-specific; the same driver-level trick could give InfiniBand or other UID-authenticated RDMA stacks a Kubernetes tenant model, though the paper demonstrates it only for Slingshot.","Editorial extension: the 30-second grace period before VNI reuse, paired with the enforced termination grace period, is what keeps straggling pods from leaking into a new tenant's VNI; node failure or a hung pod past the grace window would be the stress case that determines whether the guarantee holds in production."],"forward_implications":["A single Kubernetes annotation (vni: true or vni: <claim-name>) is enough for a job to request its own isolated Slingshot network; no privileged per-user onboarding is needed.","Pods inside one job — or several jobs redeeming the same VNI Claim — can communicate over Slingshot, while pods of unrelated jobs cannot, because each job's pods are admitted only to their own VNI.","HPC workloads running in containers keep host-level RDMA throughput and latency (overhead within run-to-run jitter, under 1%), so the isolation layer does not force a slowdown.","Job admission overhead stays near 3.5% for ramp-shaped load and 1.6% for 500-job spikes, with most admission delay attributed to Kubernetes itself rather than the new stack.","The VNI Service's atomic database transactions make concurrent VNI allocation race-free, so two jobs cannot be handed the same VNI even under admission bursts."],"supporting_citations":[{"why":"Specifies the CNI ADD/DEL interface that the CXI CNI plugin implements to create and destroy per-container CXI services.","marker":"[6]"},{"why":"Defines the Kubernetes API surface — annotations, namespaces, custom resources — that the VNI Service and CNI plugin integrate with.","marker":"[2]"},{"why":"The patched libfabric network abstraction library through which applications reach Slingshot RDMA in the evaluation.","marker":"[9]"},{"why":"Supplies the decorator-controller backend the VNI Controller uses to attach VNI custom resources to annotated jobs.","marker":"[13]"},{"why":"SQLite's ACID transactions make concurrent VNI allocation race-free in the VNI Endpoint's database.","marker":"[14]"},{"why":"The lightweight Kubernetes distribution (k3s) on which the two-node evaluation cluster runs.","marker":"[15]"},{"why":"OSU Micro-Benchmarks provide the osu_bw and osu_latency measurements behind the sub-1% communication overhead claim.","marker":"[17]"},{"why":"The Volcano scheduler spreads MPI benchmark pods across nodes in the job admission experiments.","marker":"[18]"}],"fun_headline_variants":["Container-granular Slingshot RDMA for secure HPC-cloud convergence","Per-pod RDMA isolation on Slingshot, at full speed","Multi-tenant Slingshot RDMA: container isolation, near-zero cost","Secure RDMA per container: closing the HPC-cloud gap"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The entire isolation guarantee rests on the claim that a container cannot alter or forge its network namespace identifier; if a container could join or create another namespace, the CXI service check would admit the wrong tenant.","fun_headline_variants_meta":{"raw":{"variants":["Container-granular Slingshot RDMA for secure HPC-cloud convergence","Per-pod RDMA isolation on Slingshot, at full speed","Multi-tenant Slingshot RDMA: container isolation, near-zero cost","Secure RDMA per container: closing the HPC-cloud gap"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.0003,"raw_usage":{"total_tokens":1575,"prompt_tokens":754,"completion_tokens":821,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":498,"completion_tokens_details":{"reasoning_tokens":742}},"tokens_in":498,"tokens_out":821,"duration_ms":8133,"temperature":1.0,"reasoning_tokens":742,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:53:53.526491+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Give a pod CAP_SYS_ADMIN and let it enter the network namespace of a neighbor pod, then attempt a Slingshot RDMA endpoint creation: if the CXI service for the neighbor's namespace admits it, the netns authentication is bypassable. A second test: delete a Slingshot-enabled pod, wait for its namespace inode to be recycled, create a new pod, and check whether its RDMA endpoint unexpectedly inherits the deleted pod's VNI and can see its traffic.","supporting_citations":[{"cited_title":"Container Network Interface Specification,","cited_arxiv_id":null,"evidence_quote":"Specifies the CNI ADD/DEL interface that the CXI CNI plugin implements to create and destroy per-container CXI services."},{"cited_title":"Kubernetes","cited_arxiv_id":null,"evidence_quote":"Defines the Kubernetes API surface — annotations, namespaces, custom resources — that the VNI Service and CNI plugin integrate with."},{"cited_title":"Libfabric","cited_arxiv_id":null,"evidence_quote":"The patched libfabric network abstraction library through which applications reach Slingshot RDMA in the evaluation."},{"cited_title":"[Online]","cited_arxiv_id":null,"evidence_quote":"Supplies the decorator-controller backend the VNI Controller uses to attach VNI custom resources to annotated jobs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"SQLite's ACID transactions make concurrent VNI allocation race-free in the VNI Endpoint's database."},{"cited_title":"K3s - Lightweight Kubernetes","cited_arxiv_id":null,"evidence_quote":"The lightweight Kubernetes distribution (k3s) on which the two-node evaluation cluster runs."},{"cited_title":"OSU Micro-Benchmarks","cited_arxiv_id":null,"evidence_quote":"OSU Micro-Benchmarks provide the osu_bw and osu_latency measurements behind the sub-1% communication overhead claim."},{"cited_title":"V olcano - Cloud native batch scheduling system for compute-intensive workloads","cited_arxiv_id":null,"evidence_quote":"The Volcano scheduler spreads MPI benchmark pods across nodes in the job admission experiments."}],"review_version":1}