<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-opennhp-ace-nhp-00" category="info" submissionType="independent" number="0" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-opennhp-ace-nhp-00" rel="prev"/>
  <front>
    <title abbrev="NHP">Network infrastructure Hiding Protocol</title>
    <seriesInfo name="RFC" value="0"/>
    <author fullname="Benfeng Chen">
      <organization>OpenNHP</organization>
      <address>
        <email>benfeng@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="22"/>
    <area>Security</area>
    <workgroup>ace</workgroup>
    <keyword>zero trust</keyword>
    <keyword>session layer</keyword>
    <abstract>
      <?line 36?>

<t>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.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://OpenNHP.github.io/ietf-rfc-nhp/draft-opennhp-ace-nhp.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-opennhp-ace-nhp/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        WG Working Group mailing list (<eref target="mailto:ace@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ace/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ace/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/OpenNHP/ietf-rfc-nhp"/>.</t>
    </note>
  </front>
  <middle>
    <?line 40?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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.</t>
      <t>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 <strong>visibility equates to vulnerability</strong>. In such an environment, any exposed service becomes an immediate target.</t>
      <t>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 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.</t>
      <t>This document outlines the motivations behind NHP, its design objectives, message structures, integration options, and security considerations for adoption within Zero Trust frameworks.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>NHP: Network infrastructure Hiding Protocol
SPA: Single-Packet Authorization
SDP: Software Defined Perimeter
OSI: Open Systems Interconnection model
ZTA: Zero Trust Architecture
ECC: Elliptic Curve Cryptography</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>NHP is explicitly designed to prevent unauthorized discovery of network resources. It implements multiple layers of cryptographic protection and enforces access controls before any TCP or TLS handshake occurs. As a result:</t>
      <ul spacing="normal">
        <li>
          <t>The risk of port scanning and IP enumeration is significantly reduced.</t>
        </li>
        <li>
          <t>Mutual authentication is performed at the session layer using asymmetric cryptography.</t>
        </li>
        <li>
          <t>NHP packet headers are designed to be indistinguishable from random noise to unauthenticated entities.</t>
        </li>
      </ul>
      <t>Potential threats include cryptographic downgrade attacks, traffic analysis, or exploitation of weak authentication mechanisms. Therefore, implementations must:</t>
      <ul spacing="normal">
        <li>
          <t>Use strong ECC keys (e.g., Curve25519) and modern AEAD ciphers.</t>
        </li>
        <li>
          <t>Implement replay protection and rate limiting.</t>
        </li>
        <li>
          <t>Follow best practices for key management and endpoint hardening.</t>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
    <?line 99?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This work builds upon foundational research from the <eref target="https://cloudsecurityalliance.org/">Cloud Security Alliance (CSA)</eref> and benefits from the collaborative support of the <eref target="https://www.ccf.org.cn/en/">China Computer Federation (CCF)</eref>. The authors would also like to thank the <eref target="https://github.com/OpenNHP/opennhp">OpenNHP</eref> open source community for their contributions, testing, and feedback on early implementations of the Network infrastructure Hiding Protocol (NHP).</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VY23IbNxJ9n6/oZV4sFS+Wyi7HrGwSmpJjVdmW1pTLlbjy
gJkBSawwwATAkKZd/pf9lv2yPQ3MkEPJm0pepBkQQKNPnz7dmNFolAUVtJzS
4K0MW+vuSJmlEz64pgiNk/RKlcqs6MbZYAurB5nIcyc3vODVzSArRJAr63ZT
XmezrLSFERX2K51YhpGtpTHreiQKOeL/jx9nvskr5b2yJuxqyetKiVmlNCEz
TZVLNyVMK7HxlM4fnz8dPX42Oj/PYPIsE04KmF7IonEq7AYZH3nlbFNjFEYG
2Z3cYaycZjSiz9JZgic+8JuX0SppsZMu20jTSMyibvWHXwZ4S2cafMC27PYv
/COPV0LpZOJnJcNybN2Kh4Ur1hheh1D76WTCs3hIbeS4mzbhgUnu7NbLCdZP
eN1KhXWTY+U1XAeQE549csuCUeIJGu770Nu6nThOK8fKHi2ZfBPu8TpUiFgm
mrC2jiHBzkTLRusUpBfSLCXcnK+liT/hvMKozyIAqCm1NuMvMiGQpxU/r/h1
XNgqy4x1FRZsgGbGJDi8jcfjLBuNRiRyEEoUIctu15L+GtPoEUyfkPIkqHC7
OtiVE/V6N8qFl2UXzVGMJtXdolJ6tTL4PVhSVa1lBV7Rb0yEWyYCZipTKPzg
Kd+RY+I5Nss7yCJgpWmP56S3jSswUZmN8irXkndtTIJTfcZcbK6Ckn5ML3iz
PxoVN+MZ/FMRgQRoQEVSYY2BCR4RpiQEy+F3nh7oenGViOnpKQ0JrvP0Qgrt
6eqGRFniOPB5SLV1Af94h9IiCsbT0tmK5KfaesYRZ3SSbQmkmcAecS6OhNns
HyZqq0I82pDkcsln2kjNDpRNwQfC6XGoIIo7wpZL0GlMt2uEItIMIC+VAS5x
GtOdkYPpIVU4pFhJSixIp2Qwl9puyS7jCvati9eQbBN03EwFj6CmvCab/zud
qvUU8zcKsaVVo8roEywgLhAflzDGs6XKIppmH8Fjgvm4U48K0B1td0wQ3/K0
UmWpZZZ9R1cmOAs0eO8sWyg2ySfkh7o1GL05e/7sMQ7Jj7fzmwli1VpnHPk8
mtbCM+1AmRBJE7MUQMXzsA8uUiFXGq4PmQZdDJa2MWXyj/3lodbFK14GS2N6
ZbdyIx0fgQMU+U/1WmnrLdKFwCCbyAEE/M4HWfn/x5EYcmBxa0uxS04VOygy
niC8AUczpS9ELaNPuZSGGcH5XggdCeTX+LXk1OLFTnnJYZ9djUqHaJrWBADb
rlWxpjymS2NqnEZyCeDMriX+8nlgKuXcptFmjxCVyhcWLu/ipD6dxzTb0zxY
i9yBj0ixxjYex8N+KWgrbXOh9zzxNRg+JMUHUMuI/laKOxMzjgMN5/UoqApp
MGM9gp+NDgmgLhKsVHJj9YaXRzYKGlwIbP8Sye/DcACfJfLz9DSqSfIFksFK
/8DJ09Mxdkb2ASQcWkKBnDXMVU6IXRtQlkG3UQhfjmhWkeKQvUqWCrtSEG4F
iiTV7RE/0rILQSWYYrIPFQFctezUK4KsVaVMnMaqqgoVUmEdRiZAZWEJQWNw
WoaKGkkrYACuRRJ1yT2mD6hhMX1Usio/tVj+rcpgoVyODRq57csQAiuT7k/7
QizLUdLhUavDJIoiZmGIto/aAwbf18olKiP9V1qObsBcxHnWyn9C59HiZnYS
MVrYZdiiQaGLKI8l3QDFSoIdmHSBA+N4a2O1XSmWNZZBUW44+ZKSRr2vA8qz
w6tjw41nv3vVTxV76fT0SI5XY2xkkWVDupzPTxhrmy8bz/7eRzHGkesz6ILN
TINWpcOAo+CsjlRhFbFFEwvnXp2T9ECRo9ec+4hgyU4Moy62utPX7a4WHAR4
eKTYNupoK/B75cdJPBLRtXZY9kSZptI28abHZDhYSaYMK/h3NLdmw+Hmlbxr
jISK7ykJ0B1yPSo9Dd68X9wOhuk/vb2Oz+8u//X+6t3lBT8vXs1ev94/ZO2M
xavr968vDk+HlfPrN28u316kxRilo6Fs8Gb26yD5Ori+ub26fjt7PaAuC/aA
i1TAc5kKA3QxxLzKAHDhVC65YtCL+c1//3P2hL58+ce7l/Pzs7PnX7+2L9+f
PXuCF0iNSdasgfKlVwRxlyEvpeDaicqgCWIO7dQcBVSHtd0aYpECmqcfGZnf
p/RDXtRnT35sB9jho8EOs6PBiNnDkQeLE4jfGPqGmT2aR+P3kD4+7+zXo/cO
997gDz8xv2l09v1PP2ZZBj5P/6IKZUj86Z9JQ4akn/6JKmTo+VKPTYu2LMda
0msTo1Bnv93CUI/0s17LlSHtp3SptUKKFDRv3EbSvNcuc1p01yXOj15yRXdj
2fqUJB1E6ffPIB9n03HHeyi+qOsPWmXoZjj03Z4qlElutrveFmseqlmvJ271
yd/TJd+10Fz60GbhnkK3rxeoPehH1uIOTUYBF/1RecYF5JRuUxdyx5a5c449
gIlNN8yhW8M1sJJdD4kUgPex9JnQNcSyHGOjN01oUFnudfZYgdaNu13O0m8U
klbChd+hKgcHj/t3Gd44tsOJPmspyljS4Gk/EFENADxfFhoFh/kqEpt+yDgu
AWS4BBwuJ/uKd7ifZNkNgMYbfEjNXOxldVPKexEpoQF4LuWhV8PdbQlMAJnQ
O68wAvz7fRejyx3TfXgqVDzcJ33l+f4AXeEgDg8EaUW+AqtjtN77WC4sEAOv
Wa33VS4y+/zp07Pnqdq2XcbscnZBuM9hc89oXu3vfA7dvdjdJ5jjwsjNDGPJ
C15azXeTXMa7Ie6oiunHZYdrBZojlLCkzJGeZW0hzCCeQ7MYt+DLwuzt7EFu
HRdS7pKMTTNFPE5358iBMW8yK+6M3WpZrmLqZF+m6WuILP85WEKh5eBru2lM
ubxRGmWsqePdoLsmILogv+RuKBGECflxrm1THlRgBrWIPf+j+WJ28vuj7hND
wdO6QizaSfETRoIcd39oWPCHnSGDWuTWxQs/mtU6plh7z/s4R7EWwKWqG26C
XsoOHRiev+wZ3m6346KIX0vGhZlIMzmJfKGkO+xxo8t0k9HqLjI9gFh3yU77
meKwX/uNBB1x99lk0n4ZOYmXL0pqheNXVWMYkvZ2pVxSHJU3bW/CX2EQ5lRK
l7iYcLhQUwkYQyDuM7m74v6NPnac/Q9hK2l8hhMAAA==

-->

</rfc>
