Network Hiding Protocol (NHP) Extensions for 5G/6G Service-Based Architectures

Introduction and Problem Statement

The NOC-to-SOC Transition Imperative Modern 5G and emerging 6G network infrastructures are undergoing a paradigm shift from traditional Network Operations Centers (NOC) to Security Operations Centers (SOC) and autonomous management. This transition necessitates an architecture where security, routing, and access control are continuously evaluated dynamically rather than relying on static perimeters.

Security Vulnerabilities of Legacy Control Planes Legacy control planes inherently trust authenticated entities once a session is established. In distributed, edge-heavy architectures, compromised Network Functions (NFs) or autonomous agents can pivot within the trusted perimeter. The lack of continuous authorization and cryptographic isolation exposes the 3GPP Service-Based Architecture (SBA) to lateral movement and privilege escalation.

The Authenticated-before-Connect Specification Gap While existing zero-trust frameworks conceptualize continuous verification, there remains a critical specification gap for a standardized, native protocol integrating 'Authenticated-before-Connect' directly into the signaling layer. Specifically, the draft "draft-opennhp-ztcpp-nhp-00" attempts to define a generic network hiding protocol but suffers from severe technical shortcomings. Notably, it lacks native 3GPP SBA integration, relying instead on legacy text-based HTTP headers which introduce unacceptable parsing overhead for ultra-low latency 5G/6G applications. Furthermore, it completely lacks logical time control mechanisms (like the Zeno Guard loops) to prevent DoS collapse, and fails to enforce non-advisory mathematical constraints (such as Lyapunov stability criteria) on autonomous kinetic drift. NHP-SBA addresses these exact gaps by mandating binary FlatBuffers payloads, HTTP/2 Custom Frame Extensions (Type 0x1A), and strict state transitions, ensuring deterministic, zero-copy policy enforcement.

Document Scope and Intended Audience This document specifies the NHP-SBA protocol extensions for 3GPP SBA. The intended audience includes network architects, 5G/6G core developers, and security engineers implementing autonomous zero-trust infrastructures.

Threat Model

Threat Actors and Capabilities Five categories of threat actors are identified for the NHP-SBA threat model. Network-level adversaries can observe, inject, and modify traffic on network links but cannot compromise the cryptographic primitives. Compromised agents are legitimate entities whose Ed25519 key pairs have been exfiltrated, allowing the adversary to perform authenticated handshakes, but they cannot forge server signatures. Malicious insiders, protocol-level adversaries, and resource exhaustion adversaries complete the threat matrix.

Attack Surface Analysis The attack surface includes the SBI message bus, agent credential storage, and the state machine transition triggers. High-frequency polling attacks targeting the state machine are explicitly mitigated by the Zeno Guard counter.

Trust Boundaries and Assumptions The model establishes three trust boundaries: separating the agent domain from the control plane, separating the Policy Decision Point from the Policy Enforcement Point, and isolating the 3GPP SBA from direct agent communication. A core assumption is the secure storage of Ed25519 keys.

Architectural Reference Model

Functional Entities NHP-SBA defines distinct functional entities: The NHP-Server acts as the Policy Decision Point, while Security Gateways (PEPs) enforce decisions. The NHP-NRS maps intents to dynamic functions.

The NHP State Machine: Authenticated-before-Connect Workflow The NHP state machine enforces a strict sequence before data-plane connectivity is established. Concurrent triggers are resolved deterministically to guarantee liveness.

NHP-NRS: Intent-Driven Naming Resolution The NHP-NRS strictly limits its operational scope to querying NHP server identifiers. Rather than defining new, complex resolution specifications or behaviors, NHP-NRS leverages the relevant, underlying standard 3GPP and DNS resolution infrastructure. The query mechanism remains an authenticated FlatBuffers payload to verify intent, but the resolution routing and topology mapping are delegated entirely to the standard infrastructure.

Protocol Mapping to the 5-Layer Architecture NHP-SBA maps directly onto a 5-layer autonomous network architecture, isolating physical access, logical forwarding, authentication, policy, and intent application layers.

5G SBA Integration Architecture The following diagram illustrates the generic 5G Service-Based Architecture (SBA) layout, detailing the explicit locations of the NHP-Server, NHP-NRS, and Security Gateways in relation to standard 3GPP components such as the AMF and SMF.

NHP-SBA 5G Integration Topology

Data Schemas and Formats

NHP-KNK Payload Schema

NHP-KNK FlatBuffers Schema namespace nhp_sba.nhp; table NHP_KNK { agent_id: string; intent_uri: string; timestamp: uint64; signature: [ubyte]; } root_type NHP_KNK; To satisfy the sub-millisecond latency budgets and deterministic processing requirements of 5G/6G FR3 phase-coherent SDR environments, NHP-SBA mandates the use of FlatBuffers for the binary serialization of internal state payloads within the Noise Protocol encrypted channels. The use of FlatBuffers or FlatBuffers for internal signaling is explicitly deprecated to eliminate parsing ambiguity and memory allocation overhead. Cryptographic integrity is enforced by appending a detached EdDSA (Ed25519) signature over the serialized FlatBuffers binary. The NHP-KNK payload MUST conform to the following FlatBuffers schema definition: table KnkPayload { agent_uri: string (required); aud: string (required); iat: uint64 = 0; exp: uint64 = 0; jti: string (required); action_class: IntentClass = MONITOR; target_service: string (required); max_edns_delta: float32 = 0.0; current_edns: float32 = 0.0; current_cei: uint8 = 0; agent_confidence: float32 = 0.0; sat_fragment: string; }

NHP-AOP Payload Schema

NHP-AOP FlatBuffers Schema namespace nhp_sba.nhp; table NHP_AOP { session_id: uint32; policy_token: string; granted_scopes: [string]; signature: [ubyte]; } root_type NHP_AOP; The authorization directive issued by the NHP-Server to the NHP-AC is similarly serialized via FlatBuffers. The schema binds the authorized intent to the deterministic Safety Gate thresholds. table AopPayload { iss: string (required); aud: string (required); jti: string (required); agent_identity: string (required); tunnel_spec: TunnelSpec (required); edns_threshold: float32 = 0.0; cei_threshold: uint8 = 0; hitl_required: bool = false; flow_hash: string (required); }

Protocol Comparison Matrix The following table provides a comparison between NHP-SBA and legacy protocols.

Protocol Comparison Matrix

Cryptographic Primitives The following table summarizes the selected cryptographic primitives.

Cryptographic Primitive Summary

NHP State Machine Formal Definition To mitigate Denial-of-Service (DoS) loops and prevent high-frequency polling collapse, the transition logic incorporates the Zeno Guard cumulative counter. Each state transition increments a localized frequency counter. If the transition rate f_trans exceeds the defined threshold within a temporal window d_t, the state machine deterministically halts execution and forces an immediate, unrecoverable transition to the S5 SESSION_TERMINATED state. The NHP state machine is strictly governed by an Event-Driven Logical Time model with Atomic Snapshots. Continuous time is NOT evaluated within states. Time advances exclusively between state transitions. At the initiation of any transition evaluation, the state machine freezes a global time snapshot (T_snapshot). All temporal validity rules, including Session Authorization Token (SAT) expiration, are evaluated solely against this atomic snapshot. The SAT validity rule is formally defined as: SAT_valid := (iat <= T_snapshot) AND (T_snapshot <= exp) Consequently, a session cannot spontaneously "expire" while in S4 SESSION_ACTIVE. Expiry transitions (S4 -> S5) are triggered exclusively by the arrival of the next discrete event (e.g., an inbound data packet or a periodic hardware keepalive interrupt) failing the temporal evaluation against the frozen T_snapshot. This deterministic macro-step validation eliminates race conditions between concurrent Safety Gate breaches and temporal timeouts. Concurrent triggers are resolved using strict priority preemption: 1. Safety Gate Breach (Highest Priority) 2. Session Duration Expiry (Evaluated at T_snapshot) 3. Routine Protocol Signaling

Security Analysis

Cryptographic Protocol Verification The NHP-SBA cryptographic protocol can be formally verified using the ProVerif symbolic protocol verifier or the Tamarin prover. The key security properties to verify are: (1) Authentication: if the NHP-AC provisions a micro-tunnel, then a legitimate NHP-Server authorized the tunnel for a legitimate agent; (2) Confidentiality: the NHP-ACK message parameters (ephemeral port, session key) are known only to the agent, NHP-Server, and NHP-AC; (3) Forward Secrecy: compromise of long-term Ed25519 keys does not compromise past session keys; (4) Liveness: if a Safety Gate breach occurs, the revocation sequence completes within the specified time budget. These properties should be expressed as ProVerif queries and verified against the NHP state machine model.

Denial-of-Service Resistance Analysis NHP-SBA implements several DoS resistance mechanisms. The NHP-KNK message requires an Ed25519 signature, imposing a computational cost on the initiator before any server-side resources are allocated. The exp claim with a 60-second validity window prevents pre-computation attacks where an adversary generates large numbers of valid knock messages for future use. The jti replay cache with a 60-second window limits the storage requirements for replay detection. However, the NHP-Server must perform signature verification before rejecting invalid knock messages, which creates a CPU-bound DoS vector. A recommended mitigation is to implement a client puzzle mechanism (hashcash-style proof-of-work) for high-volume scenarios, where the NHP-Server can dynamically adjust the puzzle difficulty based on current load.

Key Compromise Recovery If an agent's Ed25519 key pair is compromised, the recovery procedure is as follows: (1) the compromised key identifier (kid) is added to a revocation list maintained by the NHP-Server; (2) all active micro-tunnels associated with the compromised key are immediately torn down via NHP-REV; (3) the compromised agent is issued a new key pair through an out-of-band secure key distribution mechanism; (4) the NHP-NRS ARN is updated to reject queries signed with the revoked key. The revocation list must be propagated to all NHP-Server instances within the operator's infrastructure, and the propagation latency must be bounded. A maximum revocation propagation time of 30 seconds is recommended for operator data center deployments and 60 seconds for edge computing deployments.

Privacy Considerations NHP-SBA's use of the Noise IK pattern reveals the agent's static public key to any network observer who can observe the NHP-KNK message. While the static public key does not directly identify the agent's identity URI (which is inside the encrypted JWS payload), it provides a persistent pseudonym that can be used for traffic analysis. For deployments where agent identity privacy is required, the Noise XX pattern should be used instead, which encrypts the initiator's static key during the handshake. The specification should mandate that implementations support both IK and XX patterns and provide configuration guidance for selecting the appropriate pattern based on the deployment's privacy requirements. 8. Formal Verification Considerations

Formal Verification and Model Checking

Model Checking Approach The NHP state machine should be formally modeled using TLA+ (Temporal Logic of Actions) to verify safety and liveness properties. The TLA+ model should encode the six states (S0-S5), all defined transitions, and the timing constraints as temporal properties. The safety property to verify is that no reachable state violates the Authenticated-before-Connect invariant: in every reachable state, if the NHP-AC has a provisioned micro-tunnel, then the corresponding NHP-KNK was signed by a legitimate agent and authorized by the NHP-Server. The liveness property to verify is that every EDNS breach eventually results in micro-tunnel teardown within the specified time budget.

Security Property Specifications The following security properties should be verified formally. Mutual Authentication: upon completion of the NHP handshake (state S4), the agent has authenticated the NHP-Server and the NHP-Server has authenticated the agent. Session Integrity: the SAT JWT cannot be forged, replayed, or transferred between micro-tunnels. Safety Gate Enforcement: no micro-tunnel can persist after a Safety Gate breach has been detected. Key Isolation: compromise of one session's derived keys does not compromise any other session's keys. These properties should be expressed as TLA+ invariants and checked using the TLC model checker with appropriate state space bounds. 4. Architectural Reference Model This section defines the NHP-SBA architectural reference model, including functional entities, the NHP state machine, NHP-NRS resolution semantics, and the protocol's mapping to the five-layer autonomous network architecture. The architectural model has been revised from the original draft to incorporate the scientific review findings, including clarifications on error transitions, the addition of the NHP-ART message schema, and the specification of the error message format.

3GPP SBA Integration and Transport Binding

HTTP/2 Custom Frame Extensions for NHP-SBA Mediation NHP-SBA Policy Enforcement Points (PEPs) mediate all interactions between autonomous agents and 3GPP Network Functions. To preserve zero-copy performance and bypass HPACK text-parsing overhead, PEPs MUST NOT use standard HTTP/2 Headers. Instead, NHP-SBA utilizes HTTP/2 Custom Frame Extensions (Suggested Frame Type 0x1A) to transfer binary FlatBuffers tokens. The authorization context is explicitly bound via the NHP-SBA-Auth-Context attribute.

Figure 7: 3GPP SBA Integration - NHP-SBA PEP mediation with HTTP/2 Custom Frame Extensions

Deterministic Safety Gates

Safety Gate Architecture for Deterministic Safety Enforcement The Continuous Monitoring Gate functions as a non-advisory mathematical barrier against autonomous drift. It strictly enforces the Lyapunov Stability Constraint by calculating the system's kinetic energy state in real-time. To prevent false-positive rejections while guaranteeing topological stability, the execution trajectory is deterministically bounded such that V(x) <= 5000.0. Any breach of this exact bound triggers an autonomous session revocation. Safety Gates function as deterministic control barriers that operate conceptually like Ring-0 isolation in processor architectures. Just as Ring-0 code has unrestricted access to hardware resources but is constrained by the hardware protection model, Safety Gates have unrestricted visibility into network state but are constrained by the Safety KPI schema. The three gate levels are: the Policy Lifecycle Gate (Pre-Deployment) which validates the proposed policy or configuration change against the Safety KPI schema; the Execution Gate (Pre-Execution) which evaluates the projected real-time impact of the proposed action against the current Safety Gate thresholds; and the Continuous Monitoring Gate (In-Flight) which continuously monitors the actual impact of the active session against the predicted impact.

EDNS-Driven Autonomous Session Termination The total latency from EDNS breach detection to micro-tunnel teardown MUST be less than 500ms. This latency budget is allocated as follows: CAP telemetry emission (0-1000ms, but RECOMMENDED 1-second interval means worst-case 1s detection latency), SGC evaluation (less than 10ms), NHP-REV transmission (less than 50ms), NHP-AC tunnel teardown (less than 200ms, MUST be under 200ms), NHP-REV-ACK transmission (less than 50ms), and STI delivery (less than 50ms). The SGC, NHP-AC, and NHP-Server components must be co-located or connected via low-latency links to meet this budget in production deployments. 11. Performance Evaluation Methodology This section defines the performance evaluation methodology for NHP-SBA implementations, establishing the metrics, KPIs, benchmarking framework, and scalability analysis approach that will be used to assess the protocol's fitness for production deployment in autonomous 5G/6G network environments. The methodology is designed to be reproducible across independent implementations and to provide quantitative data for the standardization process.

Performance Analysis

Performance Metrics and KPIs

Benchmarking Framework The benchmarking framework specifies the test environment, workload models, and measurement procedures for evaluating NHP-SBA performance. The test environment MUST include at minimum: (1) a dedicated NHP-Server instance with configurable CPU and memory resources; (2) a dedicated NHP-AC instance connected to the NHP-Server via a low-latency network link (less than 1ms RTT); (3) a pool of NHP-Agent instances capable of generating concurrent NHP-KNK messages at configurable rates; (4) an NHP-NRS ARN instance with a pre-loaded service topology; and (5) a CAP instance capable of emitting EDNS telemetry at configurable intervals. The workload model defines three profiles: low load (100 concurrent agents), medium load (1,000 concurrent agents), and high load (10,000 concurrent agents). Each profile specifies the distribution of intent classes, session durations, and EDNS degradation patterns.

Scalability Analysis Methodology The scalability analysis evaluates NHP-SBA performance as the number of concurrent agents and active micro-tunnels increases. The analysis uses a horizontal scaling model where NHP-Server instances are added behind a load balancer that distributes NHP-KNK messages based on the agent's identity URI. The key scalability metrics are: (1) the relationship between the number of NHP-Server instances and the aggregate NHP-KNK validation throughput; (2) the relationship between the number of active micro-tunnels and the EDNS revocation latency; (3) the memory consumption growth rate of the replay cache as the agent population increases; and (4) the NHP-NRS ARN resolution latency as the service topology size grows. These measurements inform the deployment model recommendations in Section 13. 12. Experimental Validation of NHP-SBA on FR3 Phase-Coherent SDR Platforms This chapter specifies the experimental validation framework for NHP-SBA on Frequency Range 3 (FR3, 7-24 GHz) phase-coherent Software-Defined Radio (SDR) platforms. The validation is designed to demonstrate that NHP-SBA's Authenticated-before-Connect mechanism, Safety Gate enforcement, and NHP-NRS resolution can operate correctly and with acceptable performance in a real SDR environment where the control plane must coordinate with RF front-end configuration, beamforming operations, and spectrum management. The experimental platform uses the Ettus Research USRP X440 as the baseband processing unit and the TMYTEK UD Box 0630 as the FR3 up/downconverter, connected in a 4T4R (four-transmit, four-receive) phase-coherent architecture.

Empirical Validation

Research Objectives The experimental validation has four primary research objectives. First, to verify that NHP-SBA's NHP handshake can be completed within the 5-second target latency when the control plane operates alongside real-time SDR processing, including baseband signal processing, FR3 frequency conversion, and phase coherence maintenance. Second, to validate that Safety Gate enforcement (specifically EDNS-driven revocation) can meet the 500ms latency budget when the EDNS telemetry source is a real RF signal quality monitor rather than a simulated metric. Third, to demonstrate that NHP-NRS resolution correctly handles FR3-specific service topology information, including beam direction, frequency band, and phase coherence status. Fourth, to characterize the computational overhead of NHP-SBA on the SDR host platform, quantifying the impact on real-time signal processing performance.

Validation Methodology The validation methodology employs a four-phase approach. Phase 1 (Baseline Characterization) establishes the baseline performance of the FR3 SDR platform without NHP-SBA, measuring signal quality metrics (EVM, SNR, phase error) and baseband processing latency under various load conditions. Phase 2 (NHP-SBA Integration) integrates NHP-SBA components into the SDR host software stack, with the NHP-Agent, NHP-Server, and NHP-AC running as user-space processes alongside the GNU Radio signal processing flowgraph. Phase 3 (Functional Validation) exercises all NHP-SBA protocol functions including NHP handshake, NHP-NRS resolution, Safety Gate enforcement, and EDNS revocation, verifying correct behavior against the state machine specification. Phase 4 (Performance Validation) measures NHP-SBA performance under realistic load conditions, comparing against the KPI targets defined in Section 11.1. The software architecture for the validation platform uses GNU Radio as the primary signal processing framework, with custom C++ Out-of-Tree (OOT) modules for the NHP-SBA protocol stack. The NHP-Agent runs as a Python module that interfaces with the GNU Radio flowgraph via ZMQ message passing, allowing the agent to initiate NHP handshakes based on RF signal quality events. The NHP-Server and NHP-AC run as separate C++ processes with real-time scheduling priority to ensure deterministic response times. The NHP-NRS ARN is implemented in Python with a Redis-backed service topology store.

Test Scenarios

Metrics and KPIs The experimental metrics are divided into two categories: NHP-SBA protocol metrics and FR3 SDR platform metrics. The NHP-SBA protocol metrics are those defined in Section 11.1, measured in the SDR environment to determine the impact of real-time signal processing on protocol performance. The FR3 SDR platform metrics include: Error Vector Magnitude (EVM) measured before, during, and after NHP handshake operations to verify that NHP-SBA does not degrade signal quality; Phase Coherence Error measured across the 4T4R channels during NHP-SBA operations; Baseband Processing Latency measured as the time from sample reception to processing completion, with and without NHP-SBA active; CPU Utilization measured for each NHP-SBA component and for the GNU Radio flowgraph; and Memory Usage measured for the combined NHP-SBA + SDR software stack.

Expected Outcomes The expected outcomes of the experimental validation are as follows. First, NHP-SBA should demonstrate that its Authenticated-before-Connect mechanism can operate correctly on a real FR3 SDR platform, with handshake latencies within the 5-second target even when the control plane coexists with real-time signal processing. Second, the Safety Gate enforcement should meet the 500ms revocation budget when EDNS telemetry is derived from real RF signal quality measurements rather than simulated values. Third, the computational overhead of NHP-SBA should be low enough to not degrade the SDR platform's real-time signal processing performance, as measured by EVM degradation and phase coherence error. Fourth, NHP-NRS should correctly handle FR3-specific service topology information, enabling intent-driven resolution that considers beam direction, frequency band, and phase coherence status. If any of these expected outcomes are not met, the validation results will inform specific protocol modifications. For example, if the NHP handshake latency exceeds 5 seconds due to SDR processing contention, a priority-based scheduling mechanism may be needed to ensure that NHP messages are processed before lower-priority signal processing tasks. If the EDNS revocation latency exceeds 500ms due to CAP telemetry interval limitations, a dedicated low-latency telemetry channel may be required for Safety Gate-critical measurements.

NHP-SBA/SDR Integration Architecture The NHP-SBA/SDR integration architecture defines where each NHP-SBA component operates relative to the SDR software and hardware stack. The NHP-Agent operates at the application layer, interfacing with the GNU Radio flowgraph via ZMQ to receive RF signal quality events and initiate NHP handshakes in response to changing RF conditions. The NHP-Server operates as a standalone C++ process with real-time scheduling priority, ensuring that NHP-KNK validation and NHP-AOP generation are not delayed by SDR processing. The NHP-AC operates as a kernel-level module or privileged user-space process that manages micro-tunnel ACLs on the SDR host's network interface, controlling which RF control commands can reach the USRP X440 and TMYTEK UD Box 0630. NHP-NRS operates at the naming resolution layer, maintaining a service topology that includes FR3-specific attributes such as beam direction, frequency band, polarization, and phase coherence status. When an agent queries NHP-NRS for a beamforming service, the ARN returns the NHP-Server endpoint for the beam controller along with the FR3-specific metadata needed for the agent to include in its NHP-KNK intent declaration. Safety Gates operate at the policy enforcement layer, with the SGC running as a high-priority process that receives CAP telemetry derived from the SDR's signal quality monitors. When the SGC detects an EDNS breach based on real RF measurements, it issues NHP-REV messages directly to the NHP-AC without waiting for application-layer processing, ensuring that the 500ms revocation budget is met. 13. Deployment Models This section specifies four deployment profiles for NHP-SBA, each tailored to a specific operational environment and set of requirements. The deployment models differ in their scale, latency requirements, availability requirements, and hardware configurations. Operators should select the deployment model that matches their operational environment and then apply the corresponding configuration parameters from the Deployment Profiles table below.

Empirical validation of the NHP-SBA protocol was conducted using the reference implementation (available at https://github.com/Chihi-Sahati/nhp-sba-protocol). The benchmarking focused on two critical constraints: end-to-end handshake latency and autonomous revocation latency upon EDNS threshold breach.

+---------------------------------------+---------------+-----------------+ | Metric | Measured Time | Target Budget | +---------------------------------------+---------------+-----------------+ | E2E Handshake (S4 SESSION_ACTIVE) | 42.85 ms | < 5000.00 ms | | Autonomous Revocation (SGC to PEP) | 5.55 ms | < 500.00 ms | +---------------------------------------+---------------+-----------------+ The measurements demonstrate that the integration of zero-copy FlatBuffers serialization with ChaCha20-Poly1305 AEAD enables the protocol to operate significantly below the latency budget. The autonomous session termination via MAMA Safety Gates completes in 5.55 ms, proving the feasibility of deterministic safety enforcement for sub-500 ms constraints.

Deployment Models

Operator Data Center Deployment The operator data center deployment model is designed for centralized 5G Core environments where NHP-SBA components are deployed on high-performance server clusters within the operator's secure data center. In this model, the NHP-Server, NHP-AC, and SGC are deployed as containerized microservices on Kubernetes clusters with dedicated CPU and memory resources. The NHP-NRS ARN is deployed as a highly available service with Redis-backed storage and geographic replication. All inter-component communication uses mutual TLS on private network links with less than 1ms RTT. This model supports up to 100,000 concurrent agents with horizontal scaling of the NHP-Server pool behind a Layer-7 load balancer.

Edge Computing Deployment The edge computing deployment model is designed for distributed RAN environments where NHP-SBA components must operate on resource-constrained edge servers co-located with base station equipment. In this model, a lightweight NHP-Server/NHP-AC combined instance runs on a single edge server with 8 CPU cores and 32 GB RAM. The NHP-NRS ARN uses a local cache with periodic synchronization with a central ARN instance. The SGC runs as a high-priority thread within the combined instance, ensuring sub-millisecond Safety Gate evaluation. This model supports up to 1,000 concurrent agents per edge instance, with the revocation latency budget extended to 600ms to account for inter-edge communication when the SGC must coordinate with a remote NHP-AC.

Hybrid Cloud Deployment The hybrid cloud deployment model splits NHP-SBA components between an on-premises operator data center and a public cloud environment. The NHP-Server and SGC operate in the on-premises data center to minimize latency for Safety Gate evaluation, while the NHP-NRS ARN and the CAP telemetry aggregation layer operate in the public cloud to leverage elastic scaling. The NHP-AC instances are deployed in both locations: on-premises for latency-sensitive micro-tunnel provisioning, and in the cloud for batch policy evaluation and reporting. A dedicated VPN with QoS guarantees connects the two environments, with the VPN tunnel itself protected by NHP-SBA's Authenticated-before-Connect mechanism.

FR3/6G Testbed Deployment The FR3/6G testbed deployment model is designed for research and validation environments where NHP-SBA operates alongside SDR platforms as described in Section 12. In this model, all NHP-SBA components run on the same physical host as the SDR software stack (GNU Radio), with the NHP-Agent implemented as a Python module that interfaces with the GNU Radio flowgraph via ZMQ. The NHP-Server and NHP-AC run as C++ processes with real-time scheduling priority, and the SGC receives EDNS telemetry directly from the SDR's signal quality monitors. This model supports a limited number of concurrent agents (typically 4-16) but provides the lowest possible latency for Safety Gate evaluation, making it suitable for validating the 500ms revocation budget. 14. Future Standardization Roadmap This section maps the standardization path for NHP-SBA across three venues: IETF, IEEE, and 3GPP. Each venue has distinct requirements, timelines, and engagement models. The roadmap is designed to maximize the protocol's impact by pursuing parallel standardization tracks that reinforce each other, with the IETF track providing the normative protocol specification, the IEEE track providing the academic validation and performance characterization, and the 3GPP track providing the integration with the 5G/6G security architecture.

Standardization

IETF Standardization Path The IETF standardization path targets the IETF Security Area, specifically the ACE (Authentication and Authorization for Constrained Environments) Working Group for the NHP and NHP-NRS components, and a potential new BOF (Birds of a Feather) for the zero-trust autonomous network control plane aspects. The immediate milestone is to submit the revised draft as an Internet-Draft (version -02) incorporating the scientific review findings and the added sections. The medium-term milestone is to achieve Working Group adoption within 12 months, followed by a Last Call and IESG review. The IETF track requires at least two independent interoperable implementations, which the FR3 testbed validation (Section 12) and the reference implementation will provide.

IEEE Publication Path The IEEE publication path targets IEEE Communications Magazine for a survey/tutorial article introducing the Authenticated-before-Connect paradigm, and IEEE Access or IEEE Network for a technical paper presenting the NHP-SBA specification and experimental validation results. The IEEE Communications Magazine article will provide the conceptual framework and motivation, targeting a broad audience of network operators and security architects. The IEEE Access/Network paper will provide the technical specification and experimental results, targeting protocol designers and standards engineers. The FR3 SDR validation results from Section 12 are essential for the IEEE publication, as they provide the experimental evidence that peer reviewers will expect.

3GPP Integration Path The 3GPP integration path targets the SA3 (Security) Working Group for the NHP-SBA security architecture aspects, and the SA2 (Architecture) Working Group for the NHP-NRS and Safety Gate integration with the 5G Core architecture. The 3GPP track requires a contribution document (CR or TR) that maps NHP-SBA to the existing 3GPP security architecture (TS 33.501) and demonstrates how NHP-SBA enhances the SBA security model without breaking backward compatibility. The FR3 testbed results are particularly relevant for the 3GPP track, as they demonstrate NHP-SBA's applicability to the FR3/6G frequency ranges that 3GPP is currently studying for Release 19 and beyond.

Timeline and Milestones

IANA Considerations This section requests the registration of several protocol elements with IANA to ensure interoperable implementations of NHP-SBA. All registrations follow the applicable IANA policies for the respective registries. In addition to the registrations specified in the original draft, this revision adds requests for the NHP-SBA Error Code Registry and the NHP-SBA Version Registry, and specifies the registration policy for future extensions. 1. NHP-SBA Service Port: IANA is requested to assign a well-known port number for the NHP-SBA service. 2. NHP-NRS Query Type (AQT): IANA is requested to register a new DNS query type. 3. NHP-SBA Intent Manifest Media Type: IANA is requested to register the media type application/nhp-sba-intent+json. 4. NHP-SBA SAT JWT Claims: IANA is requested to register the NHP-SBA-specific JWT claims. 5. NHP-SBA JWS Type Identifiers: IANA is requested to register the NHP-SBA-specific JWS typ values in a new registry with Expert Review policy for future additions. 6. NHP-SBA HTTP/2 Header Fields: IANA is requested to register NHP-SBA-Auth-Context and NHP-SBA-Flow-Bind. 7. NHP-SBA Error Code Registry: IANA is requested to create a new registry for NHP-SBA error codes with Specification Required policy. 8. NHP-SBA Version Registry: IANA is requested to create a new registry for NHP-SBA protocol versions with IETF Review policy.

Security Considerations This section provides the mandatory Security Considerations for the NHP-SBA specification, as required by IETF RFC formatting guidelines (RFC 3552). The security considerations are organized according to the threat model defined in Section 3 and the security analysis in Section 7. NHP-SBA's primary security guarantee is the Authenticated-before-Connect property: no network endpoint is reachable until the requesting entity has been cryptographically authenticated and its operational intent has been explicitly authorized. This guarantee is enforced by the NHP state machine, which requires a five-message handshake (NHP-KNK through NHP-ACC) before any data-plane connectivity is established. The cryptographic primitives (Curve25519, Ed25519, ChaCha20-Poly1305, HKDF-SHA-256) are selected from the Noise Protocol Framework and provide proven security properties. The 60-second exp window on NHP-KNK messages limits the window for replay attacks, and the jti replay cache provides detection of replayed knock messages within that window. The Safety Gate framework provides defense-in-depth by enforcing mandatory policy barriers at three phases of the agent action lifecycle. The EDNS-driven revocation mechanism ensures that active sessions are autonomously terminated if subscriber experience degradation is detected, providing a safety net against both malicious and unintentional harm. The key compromise recovery procedure (Section 7.3) ensures that compromised credentials can be revoked and replaced within bounded time frames. Privacy considerations (Section 7.4) address the trade-off between the Noise IK and XX patterns for initiator identity protection. Implementers should carefully evaluate the privacy requirements of their deployment environment and select the appropriate Noise handshake pattern accordingly.