



saag                                                             B. Chen
Internet-Draft                                                   OpenNHP
Intended status: Informational                           19 October 2025
Expires: 22 April 2026


                 Network infrastructure Hiding Protocol
                        draft-opennhp-ace-nhp-01

Abstract

   The Network infrastructure Hiding Protocol (NHP) is a cryptography-
   based session-layer protocol designed to implement Zero Trust
   principles by rendering protected network resources invisible to
   unauthorized entities.  By requiring authentication before connection
   and operating at OSI layers 5 , NHP conceals IP addresses, ports, and
   domains from exposure to reconnaissance and automated exploitation,
   effectively reducing the attack surface.  This draft defines the
   architecture, message format, and workflow of the NHP protocol,
   outlines its security objectives, and provides guidance for
   integration into modern network infrastructures and Zero Trust
   deployments.

   title: "Network-Infrastructure Hiding Protocol (NHP)" abbrev: "NHP"
   docname: draft-opennhp-ace-nhp-01 category: informational stream:
   independent submissiontype: independent number: 00 date: 2025-10-19
   v: 1 area: "Security" workgroup: "secdp" keyword:

   *  zero trust

   *  session layer

   *  network obfuscation venue: group: "saag" type: "Independent
      Submission" mail: "saag@ietf.org (mailto:saag@ietf.org)" arch:
      "https://mailarchive.ietf.org/arch/browse/secdp/
      (https://mailarchive.ietf.org/arch/browse/secdp/)" github:
      "OpenNHP/ietf-rfc-nhp" latest: "https://OpenNHP.github.io/ietf-
      rfc-nhp/draft-opennhp-ace-nhp.html (https://OpenNHP.github.io/
      ietf-rfc-nhp/draft-opennhp-ace-nhp.html)"

   author:

   *  fullname: Benfeng Chen organization: OpenNHP email:
      benfeng@gmail.com (mailto:benfeng@gmail.com)

   normative:

   *  RFC2119



Chen                      Expires 22 April 2026                 [Page 1]

RFC 1                              NHP                      October 2025


   *  RFC8174

   *  RFC9000

   *  RFC8446

   *  RFC9180

   *  NoiseFramework

   informative:

   *  NIST.SP.800-207

   *  CSA.SDP.Spec2.0

   *  CSA.SDP.Architecture.3.0

   *  CSA.ZeroTrust.GuidingPrinciples

   *  CSA.AsymmetricCrypto.ZT

   *  OpenNHP.Readme

   The Network-Infrastructure Hiding Protocol (NHP) is a cryptography-
   based session-layer protocol designed to operationalize Zero Trust
   principles by concealing protected network resources from
   unauthorized entities.  NHP enforces authentication-before-connect
   access control, rendering IP addresses, ports, and domain names
   invisible to unauthorized users.  This document defines the protocol
   architecture, cryptographic framework, message format, and workflow
   to enable independent implementation of NHP.  It also provides
   guidance for integration with Software-Defined Perimeter (SDP), DNS,
   and Zero Trust policy engines.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://OpenNHP.github.io/ietf-rfc-nhp/draft-opennhp-ace-nhp.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-opennhp-ace-nhp/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:saag@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ace/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/saag/.



Chen                      Expires 22 April 2026                 [Page 2]

RFC 1                              NHP                      October 2025


   Source for this draft and an issue tracker can be found at
   https://github.com/OpenNHP/ietf-rfc-nhp.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  2.  Conventions and Definitions . . . . . . . . . . . . . . .   4
   3.  3.  Design Objectives . . . . . . . . . . . . . . . . . . . .   5
   4.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  2.  Terminology and Conventions . . . . . . . . . . . . . . .   6
   6.  3.  Design Objectives . . . . . . . . . . . . . . . . . . . .   6
   7.  4.  Architectural Overview  . . . . . . . . . . . . . . . . .   6
     7.1.  4.1 Component Interactions and Deployment Models  . . . .   7
   8.  5.  Protocol Workflow . . . . . . . . . . . . . . . . . . . .   8
     8.1.  5.1 Control Plane vs Data Plane . . . . . . . . . . . . .   8
     8.2.  5.2 NHP Workflow Steps  . . . . . . . . . . . . . . . . .   8
     8.3.  5.3 Sequence Diagram  . . . . . . . . . . . . . . . . . .   9
   9.  6.  Cryptographic Framework . . . . . . . . . . . . . . . . .   9
   10. 7.  Message Structure . . . . . . . . . . . . . . . . . . . .   9
   11. 8.  Security Considerations . . . . . . . . . . . . . . . . .  10



Chen                      Expires 22 April 2026                 [Page 3]

RFC 1                              NHP                      October 2025


   12. 9.  IANA Considerations . . . . . . . . . . . . . . . . . . .  10
   13. 10.  Reference Implementation . . . . . . . . . . . . . . . .  10
   14. 11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . .  10
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Normative References . . . . . . . . . . . . . . . .  10
   Appendix B.  Informative References . . . . . . . . . . . . . . .  11
   Appendix C.  IANA Considerations  . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  1.  Introduction

   Since its inception in the 1970s, the TCP/IP networking model has
   prioritized openness and interoperability, laying the foundation for
   the modern Internet.  However, this design philosophy also exposes
   systems to reconnaissance and attack.

   Today, the cyber threat landscape has been dramatically reshaped by
   the rise of AI-driven attacks, which bring unprecedented speed and
   scale to vulnerability discovery and exploitation.  Automated tools
   continuously scan the global network space, identifying weaknesses in
   real-time.  As a result, the Internet is evolving into a "Dark
   Forest," where *visibility equates to vulnerability*. In such an
   environment, any exposed service becomes an immediate target.

   The Zero Trust model, which mandates continuous verification and
   eliminates implicit trust, has emerged as a modern approach to
   cybersecurity.  Within this context, the Network infrastructure
   Hiding Protocol (NHP) offers a new architectural element:
   authenticated-before-connect access at the session layer.  Inspired
   by Cloud Security Alliance’s Single-Packet Authorization (SPA) and
   Software Defined Perimeter (SDP) technologies, NHP advances the
   concept further by using cryptographic protocols (e.g., Noise, ECC)
   to obfuscate infrastructure and enforce granular access control.

   This document outlines the motivations behind NHP, its design
   objectives, message structures, integration options, and security
   considerations for adoption within Zero Trust frameworks.

2.  2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.





Chen                      Expires 22 April 2026                 [Page 4]

RFC 1                              NHP                      October 2025


   NHP: Network-Infrastructure Hiding Protocol SPA: Single-Packet
   Authorization SDP: Software-Defined Perimeter ZTA: Zero Trust
   Architecture ECC: Elliptic Curve Cryptography AEAD: Authenticated
   Encryption with Associated Data NAC: Network Access Control

3.  3.  Design Objectives

   The NHP protocol is designed to:

   *  Eliminate unauthorized network visibility by enforcing
      authentication prior to session establishment.

   *  Operate at the OSI Session Layer, complementing existing TCP, UDP,
      and QUIC transports.

   *  Support decentralized trust using asymmetric cryptography and
      ephemeral key exchange.

   *  Enable fine-grained, context-based policy enforcement across
      heterogeneous environments.

   *  Integrate with existing Zero Trust controllers, SDP gateways, and
      identity systems.

4.  1.  Introduction

   Since the 1970s, TCP/IP has provided universal connectivity but also
   exposed every reachable service to reconnaissance and attack.  Modern
   AI-driven reconnaissance and exploitation tools can automatically
   identify and compromise exposed endpoints, turning Internet
   visibility into vulnerability.  This document introduces the Network-
   Infrastructure Hiding Protocol (NHP), a session-layer mechanism that
   enforces authenticated-before-connect access, ensuring that only
   authorized clients can detect and reach protected resources.

   NHP builds upon foundational work in the Cloud Security Alliance’s
   Software-Defined Perimeter (SDP) and Single-Packet Authorization
   (SPA) frameworks, extending them with modern asymmetric cryptography
   and Noise Protocol-based mutual authentication.  NHP replaces
   traditional perimeter visibility with a cryptographically controlled,
   context-aware trust fabric.










Chen                      Expires 22 April 2026                 [Page 5]

RFC 1                              NHP                      October 2025


5.  2.  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   NHP: Network-Infrastructure Hiding Protocol SPA: Single-Packet
   Authorization SDP: Software-Defined Perimeter ZTA: Zero Trust
   Architecture ECC: Elliptic Curve Cryptography AEAD: Authenticated
   Encryption with Associated Data NAC: Network Access Control

6.  3.  Design Objectives

   The NHP protocol is designed to:

   *  Eliminate unauthorized network visibility by enforcing
      authentication prior to session establishment.

   *  Operate at the OSI Session Layer, complementing existing TCP, UDP,
      and QUIC transports.

   *  Support decentralized trust using asymmetric cryptography and
      ephemeral key exchange.

   *  Enable fine-grained, context-based policy enforcement across
      heterogeneous environments.

   *  Integrate with existing Zero Trust controllers, SDP gateways, and
      identity systems.

7.  4.  Architectural Overview

   NHP operates as a distributed session-layer protocol that enforces
   authentication-before-connect access between clients and protected
   resources.  The architecture includes three primary components:

   *  *NHP-Agent* – a client-side process or SDK that initiates
      communication with the protected network by generating and sending
      an NHP-KNK message to the NHP-Server.  It performs cryptographic
      key exchange and authentication using Noise-based handshakes.

   *  *NHP-Server* – the core control-plane service that receives and
      validates NHP-KNK messages, authenticates the NHP-Agent, and
      determines access decisions.  The NHP-Server interfaces with
      external *Authorization Service Providers (ASP)* or IAM systems to
      evaluate identity, context, and policy.  It also manages



Chen                      Expires 22 April 2026                 [Page 6]

RFC 1                              NHP                      October 2025


      communication with NHP-AC components, instructing them to open or
      close access paths.  Functionally, the NHP-Server maps to the
      *Policy Administrator* role defined in *NIST SP 800-207 Zero Trust
      Architecture*, responsible for policy evaluation and decision-
      making.

   *  *NHP-AC (Access Controller)* – the enforcement component residing
      logically or physically near protected resources.  Upon receiving
      an NHP-AOP command from the NHP-Server, the NHP-AC updates its
      access control tables, temporarily allowing the NHP-Agent to reach
      the protected resource.  It automatically reverts to the default-
      deny state when the session expires.  The NHP-AC corresponds to
      the *Policy Enforcement Point (PEP)* in NIST SP 800-207
      terminology.

   In this model, authentication, authorization, and access enforcement
   are strictly decoupled.  The NHP-Agent never directly accesses the
   NHP-AC without prior validation by the NHP-Server.  This structure
   supports horizontal scalability and allows multiple NHP-Servers and
   NHP-ACs to operate in cluster configurations for redundancy and high
   availability.

7.1.  4.1 Component Interactions and Deployment Models

   NHP components can be deployed in different configurations depending
   on the size and topology of the protected network:

   *  *Standalone Deployment:* For small environments or testing
      scenarios, the NHP-Server and NHP-AC can coexist on the same host.
      This configuration simplifies setup while maintaining full
      protocol compliance.

   *  *Clustered Deployment:* In enterprise or cloud environments,
      multiple NHP-Servers can be deployed in a load-balanced cluster.
      Each server manages a pool of NHP-AC instances distributed across
      data centers or network segments.  The NHP-Agent dynamically
      discovers the nearest NHP-Server through DNS or bootstrap
      configuration.

   *  *Edge AC Deployment:* Edge nodes (e.g., gateways, routers, or
      micro-segmentation agents) can host lightweight NHP-AC components.
      These edge ACs enforce fine-grained policies close to workloads,
      improving latency and fault isolation.








Chen                      Expires 22 April 2026                 [Page 7]

RFC 1                              NHP                      October 2025


   *  *Multi-Tenant Deployment:* In service-provider or multi-cloud
      environments, each tenant can operate an independent NHP-Server
      while sharing an underlying AC infrastructure.  The NHP protocol’s
      namespace isolation ensures complete tenant separation through
      identity-scoped keys and per-tenant policy databases.

   This modular architecture provides flexibility for diverse Zero Trust
   environments—from on-premises datacenters to global cloud
   infrastructures—while maintaining the core NHP principles of
   invisibility, least privilege, and continuous verification.

8.  5.  Protocol Workflow

8.1.  5.1 Control Plane vs Data Plane

   The *Control Plane* carries cryptographic authentication and
   authorization information among NHP-Agent, NHP-Server, NHP-AC, and
   optional external *Authorization Service Providers (ASP)*. The *Data
   Plane* carries application data between the resource requester (NHP-
   Agent host) and the protected resource, but only after NHP-AC
   explicitly authorizes access.  This strict separation enforces the
   _authenticate-before-connect_ principle.

8.2.  5.2 NHP Workflow Steps

   1.  NHP-Agent sends *NHP-KNK* to *NHP-Server*.

   2.  NHP-Server validates and queries *ASP*.

   3.  ASP returns authorization decision.

   4.  NHP-Server sends *NHP-AOP* to *NHP-AC*.

   5.  NHP-AC enforces and replies with *NHP-ART*.

   6.  NHP-Server sends *NHP-ACK/AOP* to *NHP-Agent*.

   7.  NHP-Agent connects using *NHP-ACC*.

   8.  NHP-Server and NHP-AC maintain *Keepalive/Logs*.

   9.  Logs uploaded for compliance and auditing.









Chen                      Expires 22 April 2026                 [Page 8]

RFC 1                              NHP                      October 2025


8.3.  5.3 Sequence Diagram

   NHP-Agent NHP-Server NHP-AC ASP / IAM |--- NHP-KNK ---> | | | | |--
   Auth Query ------------------------> | | |<-- Auth Result
   ----------------------- | | |-- NHP-AOP (open-door) -->| | | |<--
   NHP-ART (result) -----| | |<-- NHP-ACK/AOP --| | | |--- NHP-ACC
   ---------------------------->| | |<============ Data Access Session
   ==============>| | | |-- NHP-LOG / LAK --------->| |

9.  6.  Cryptographic Framework

   NHP employs the *Noise Protocol Framework* using the *XX* handshake
   pattern by default for full forward secrecy and identity protection,
   or *K* pattern for performance-optimized one-way initiation.
   Recommended primitives:

   *  DH function: Curve25519

   *  Cipher: ChaCha20-Poly1305

   *  Hash: SHA-256

   *  Key Derivation: HKDF

10.  7.  Message Structure

     +================+==========+==================================+
     | Field          | Size     | Description                      |
     +================+==========+==================================+
     | Version        | 1 byte   | Protocol version (0x01)          |
     +----------------+----------+----------------------------------+
     | Type           | 1 byte   | Message type code                |
     +----------------+----------+----------------------------------+
     | Flags          | 1 byte   | Control flags                    |
     +----------------+----------+----------------------------------+
     | Nonce          | 12 bytes | AEAD nonce for replay protection |
     +----------------+----------+----------------------------------+
     | Timestamp      | 8 bytes  | UNIX epoch time (ms)             |
     +----------------+----------+----------------------------------+
     | Payload Length | 2 bytes  | Encrypted payload length         |
     +----------------+----------+----------------------------------+

                                 Table 1








Chen                      Expires 22 April 2026                 [Page 9]

RFC 1                              NHP                      October 2025


11.  8.  Security Considerations

   NHP ensures infrastructure invisibility by encrypting all handshake
   traffic and performing mutual authentication before connection
   establishment.  Implementations MUST use strong ECC keys, prevent
   replay, and maintain session expiration enforcement.

12.  9.  IANA Considerations

   This document has no IANA actions.

13.  10.  Reference Implementation

   An open-source reference implementation of NHP is available at:
   *https://github.com/OpenNHP/opennhp (https://github.com/OpenNHP/
   opennhp)*

14.  11.  Acknowledgments

   This work extends concepts from the Cloud Security Alliance SDP WG
   and integrates guidance from NIST SP 800-207 and CSA Zero Trust
   research.

15.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Appendix A.  Normative References

   [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate
   Requirement Levels”, 1997.  [RFC8174] Leiba, B., “Ambiguity of
   Uppercase vs Lowercase in RFC 2119 Key Words”, 2017.
   [NoiseFramework] Perrin, T., “The Noise Protocol Framework”, 2018.











Chen                      Expires 22 April 2026                [Page 10]

RFC 1                              NHP                      October 2025


Appendix B.  Informative References

   [NIST.SP.800-207] Rose, S., Borchert, O., Mitchell, S., and Connelly,
   S., “Zero Trust Architecture”, 2020.  [CSA.SDP.Spec2.0] CSA,
   “Software Defined Perimeter Specification v1.0”, 2021.
   [CSA.SDP.Architecture.3.0] CSA, “SDP Architecture Guide v3.0”, 2025.
   [CSA.ZeroTrust.GuidingPrinciples] CSA, “Zero Trust Guiding
   Principles”, 2024.  [CSA.AsymmetricCrypto.ZT] CSA, “Using Asymmetric
   Cryptography to Help Achieve Zero Trust Objectives”, 2024.
   [OpenNHP.Readme] Chen, B., “OpenNHP: Open Source Zero Trust Security
   Toolkit”, GitHub, 2025.

Appendix C.  IANA Considerations

   This document has no IANA actions.

Acknowledgments

   This work builds upon foundational research from the Cloud Security
   Alliance (CSA) (https://cloudsecurityalliance.org/) and benefits from
   the collaborative support of the China Computer Federation (CCF)
   (https://www.ccf.org.cn/en/).  The authors would also like to thank
   the OpenNHP (https://github.com/OpenNHP/opennhp) open source
   community for their contributions, testing, and feedback on early
   implementations of the Network infrastructure Hiding Protocol (NHP).

Author's Address

   Benfeng Chen
   OpenNHP
   Email: benfeng@gmail.com




















Chen                      Expires 22 April 2026                [Page 11]
