Paying for Trust at the Edge: Secure, Lightweight, Deadline-Aware Named Data Networking for Edge-Cloud Compute Orchestration
TL;DR
SLED is developed, a secure edge--cloud framework over NDN that incorporates a Security Verification Engine (SVE) into the edge compute budget, explicitly coupling verification occupancy with named-function execution and demonstrates that verification should be treated as a first-class resource cost and jointly optimised with workload placement and deadline requirements.
Abstract
Edge nodes are among the most resource-constrained components of computing infrastructure, yet security verification competes directly with application execution for limited compute resources. In Named Data Networking (NDN), each retrieved object carries a producer signature whose verification consumes edge CPU cycles, while existing cryptographic and orchestration studies rarely quantify its impact on service reliability. This paper develops SLED, a secure edge--cloud framework over NDN that incorporates a Security Verification Engine (SVE) into the edge compute budget, explicitly coupling verification occupancy with named-function execution. SLED combines DACSIR, which prices verification into deadline-aware cache-assisted routing; LSAV, which amortises one Ed25519 signature over a Merkle tree covering $B$ Data packets and re-validates cached objects using symmetric tokens within a trust domain; and DREP, which dynamically provisions and reclaims cloud burst workers according to edge utilisation. Cryptographic costs measured on a host CPU were scaled to individual tiers using modelling factors and incorporated into a discrete-event simulator. At 6,000 Interests per second, SLED achieves a deadline satisfaction ratio of 0.978, compared with 0.952 for the same datapath using per-packet RSA-2048 and 0.600 for vanilla NDN, while reducing mean per-request verification latency from 7,150.5 to 258.4~$\mu$s and recovering 94.5% of the insecure upper-bound utility. Replacing RSA-2048 with Ed25519 alone yields little improvement, indicating that reliability is more sensitive to verification frequency than to the cryptographic primitive in the evaluated configurations. These results demonstrate that verification should be treated as a first-class resource cost and jointly optimised with workload placement and deadline requirements, while noting that system-level results are simulation-based and per-tier scaling factors are estimated.