Internet Agent Communication Protocol - DHT
draft-gebauer-iacp-dht-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Leonard Gebauer | ||
| Last updated | 2026-07-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gebauer-iacp-dht-00
Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 28 July 2026
Expires: 29 January 2027
Internet Agent Communication Protocol - DHT
draft-gebauer-iacp-dht-00
Abstract
Ever since 1969 and the ARPANET, the internet has repeatedly been
faced with challenges that it has had to overcome—and has overcome.
Year after year, the number of users has grown, and year after year,
the complexity and range of ways in which the internet can be used
have expanded. With the advent of AI, we not only have a new type of
user, we have a different form of communication; the internet itself
is being attributed a completely different significance. If they are
not already, AIs will make up the majority of internet users in the
foreseeable future. The question of an ‘AgentNet,’ is not merely a
question concerning the internet; it is a question of how AIs will
interact within a global network in the future.
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 29 January 2027.
Copyright Notice
Copyright (c) 2026 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.
Gebauer Expires 29 January 2027 [Page 1]
Internet-Draft IACP - DHT July 2026
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. DHT Namespace Architecture and Distributed Security . . . . . 3
2.1. Distributed Hash Table . . . . . . . . . . . . . . . . . 3
2.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. DHT Namespace Structure . . . . . . . . . . . . . . . 3
2.1.3. DHT Overlay Construction . . . . . . . . . . . . . . 4
2.2. Namespace Registration and Curation . . . . . . . . . . . 19
2.2.1. Root Namespace Registration . . . . . . . . . . . . . 19
2.2.2. Sub-Namespace Delegation . . . . . . . . . . . . . . 20
2.3. Proof-of-Work and Reputation-Based Access Control . . . . 20
2.3.1. Dynamic PoW Difficulty . . . . . . . . . . . . . . . 21
2.3.2. Access Tickets and Joint Liability . . . . . . . . . 21
2.4. Anti-Abuse Mechanisms . . . . . . . . . . . . . . . . . . 21
2.4.1. Token-Bucket Filters and Rate Limiting . . . . . . . 22
2.4.2. Autonomous Circuit Breakers . . . . . . . . . . . . . 22
2.5. Proof of Malfeasance (PoM) and Slashing . . . . . . . . . 22
2.5.1. PoM Ticket Specification . . . . . . . . . . . . . . 22
2.5.2. Two-Phase Slashing Escrow (2PSE) . . . . . . . . . . 34
2.5.3. Curator Quarantine and Decapitation . . . . . . . . . 34
2.5.4. Reputation Penalties . . . . . . . . . . . . . . . . 35
2.6. Compromise Recovery and Hot-Docking . . . . . . . . . . . 35
2.6.1. Migration Stream Serialization . . . . . . . . . . . 35
2.6.2. Migration Stream Encryption . . . . . . . . . . . . . 35
2.6.3. Forwarding Ticket Generation . . . . . . . . . . . . 36
2.6.4. Migration Flow . . . . . . . . . . . . . . . . . . . 36
2.6.5. EID Revocation and Propagation . . . . . . . . . . . 37
2.7. Layer-Separated Economic Governance and Edge Gatekeeper
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.1. Layer 4 Kernel-Space Fast-Path . . . . . . . . . . . 40
2.7.2. Layer 7 Application-Space Door-Keeper (Opaque
Authorization Envelope) . . . . . . . . . . . . . . . 42
2.7.3. Asynchronous Verification and Teardown . . . . . . . 42
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1. Normative References . . . . . . . . . . . . . . . . . . 43
3.2. Informative References . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
Gebauer Expires 29 January 2027 [Page 2]
Internet-Draft IACP - DHT July 2026
1. Introduction
This document is merely a sub-I-D of the main I-D. For appendices,
acknowledgments, Security Considerations, IANA Considerations and
other information, please refer to the main I-D. This sub-I-D
contains only a 1:1 copy of the chapter it covers, to provide a
better basis for discussion.
1.1. Requirements Language
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.
2. DHT Namespace Architecture and Distributed Security
2.1. Distributed Hash Table
2.1.1. General
The Internet Agent Communication Protocol (IACP) utilizes a globally
distributed, decentralized lookup architecture based on a Distributed
Hash Table (DHT) to maintain public records without relying on
centralized single points of failure. The routing infrastructure
operates as an overlay network where participating nodes collectively
maintain the mapping directory, ensuring high availability, fault
tolerance, and resilience against targeted node churn.
2.1.2. DHT Namespace Structure
The DHT primary key space uses a flat, uniform 256-bit space
generated via cryptographic hashing (KEY = SHA-256("path")). The
structural mapping within the global directory maps an absolute
string identifier or specific spatial coordinate to its respective
destination metadata object, primarily an Ephemeral Agent Identity
(EID) or a transport boundary mapping vector. Namespaces use
deterministic hierarchical reverse-notation paths (e.g.
org.agentnet.marketplace.energy).
Gebauer Expires 29 January 2027 [Page 3]
Internet-Draft IACP - DHT July 2026
+---------------------------------------------------------------------+
| DHT 256-Bit Uniform Keyspace |
+---------------------------------------------------------------------+
| [0x0000...0000] [0xFFFF...FFFF] |
+---------------------------------------------------------------------+
| |
v v
SHA-256(Namespace String) SHA-256(EID)
To enforce separation between functional routing environments and
semantic application layers, the DHT segregates the cryptographic
keyspace using explicit namespace routing bits embedded within the
target coordinate schema.
2.1.3. DHT Overlay Construction
The IACP DHT overlay is structured as a Kademlia-based distributed
hash table [Kademlia] with a 256-bit identifier space. Each
participating node is assigned a Node ID, which is the SHA-256 hash
of its EID.
2.1.3.1. Peer Discovery and Bootstrap
A node joining the IACP DHT overlay MUST obtain at least one
bootstrap entry point. Bootstrap entries MAY be obtained through:
1. Static Bootstrap Nodes: A set of well-known, stable nodes
operated by the namespace curator or infrastructure provider.
These are configured out-of-band.
2. DNS-based Discovery: A DNS SRV record [RFC2782] for _iacp-
dht._udp.{namespace} MAY be used to discover bootstrap nodes.
3. Cache Persistence: Nodes SHOULD persist a local cache of
previously known peers to accelerate rejoining.
Upon obtaining bootstrap contact, the node performs a Kademlia
FIND_NODE operation to populate its routing table (k-buckets). The
routing table uses a bucket size of k = 20.
2.1.3.2. Routing Table Maintenance
Each node maintains a routing table of k-buckets organized by XOR
distance from its own Node ID. Buckets are structured as follows:
* Bucket 0: peers with a shared prefix length of 255 bits (closest)
* Bucket i: peers with a shared prefix length of (255 - i) bits
Gebauer Expires 29 January 2027 [Page 4]
Internet-Draft IACP - DHT July 2026
* Maximum bucket size: k = 20
When a bucket is full and a new peer is discovered, the node pings
the least-recently-seen peer in the bucket. If the peer responds,
the new peer is not added. If the peer does not respond, it is
evicted and the new peer is added.
2.1.3.3. Replication and Redundancy
To ensure availability under churn, each key-value pair (EID-to-
locator mapping or Forwarding Ticket) MUST be stored on the k closest
nodes to the key, where k = 20. Additionally:
* Replication Factor: r = 7 (the key is stored on the 7 closest
nodes).
* Republish Interval: Nodes MUST republish their own mappings every
T_republish = 24 hours.
* Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes
MUST refresh a mapping before expiration by re-issuing the STORE
operation.
2.1.3.4. Lookup Operations
Lookups for an EID coordinate follow the standard Kademlia iterative
lookup:
1. The initiating node selects alpha = 3 nodes from its routing
table closest to the target key.
2. It sends parallel FIND_NODE requests to these nodes.
3. Each responding node returns the k closest nodes it knows to the
target key.
4. The initiator updates its routing table with the responses and
continues the iterative process until it has contacted the
closest nodes or until no closer nodes are found.
The lookup is considered successful if the target key is found or if
the closest nodes report that the key does not exist.
2.1.3.5. Anti-Eclipse and Sybil Protections
To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces
the following:
Gebauer Expires 29 January 2027 [Page 5]
Internet-Draft IACP - DHT July 2026
1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which
already require Proof-of-Work for registration (see Section 5.3).
This makes Sybil generation computationally expensive.
2. Randomized Bucket Selection: When selecting nodes for lookup
operations, the initiator SHOULD include a random selection from
the k-bucket in addition to the closest nodes to prevent an
attacker from monopolizing a bucket.
3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5
minutes) ping the least-recently-seen peer in each bucket to
detect churn and evict stale entries.
2.1.3.6. Lookup Flow
The iterative lookup process follows this flow:
+-------------+ +-------------+ +-------------+
| Initiator | | Node A | | Node B |
+-------------+ +-------------+ +-------------+
| | |
| 1. FIND_NODE | |
|------------------>| |
| | |
| 2. RETURN k | |
|<------------------| |
| | |
| 3. FIND_NODE | |
|-------------------------------------->|
| | |
| 4. RETURN k | |
|<--------------------------------------|
| | |
v (Continue until closest nodes found) v
+-------------+ +-------------+ +-------------+
| Result | | Closest | | Closest |
| Found | | Node Set | | Node Set |
+-------------+ +-------------+ +-------------+
2.1.3.7. Global Directory Quorum and Consensus
2.1.3.7.1. Quorum Formation
A Global Directory Quorum for a given EID or key is formed as
follows:
Gebauer Expires 29 January 2027 [Page 6]
Internet-Draft IACP - DHT July 2026
1. Candidate Selection: The initiating node selects the k = 20
closest nodes to the target key (SHA-256(EID) for EID mappings,
SHA-256(Namespace) for namespace operations) from its routing
table.
2. Quorum Selection: From these 20 candidates, the quorum is formed
by selecting a deterministic subset of n = 7 nodes. The
selection uses the following algorithm:
* Sort the 20 candidates by XOR distance to the target key.
* Apply a pseudo-random permutation seeded by the target key:
PRP_key = SHA-256(target_key || "IACP_QUORUM_SALT")
* Select the first 7 nodes from the permuted list.
This randomized selection prevents an attacker from predicting or
monopolizing the quorum for a specific key.
3. Quorum Set: The resulting set Q = {q1, q2, ..., q7} constitutes
the Global Directory Quorum for the target key. The quorum set
is valid for T_quorum = 1 hour from the time of selection. After
T_quorum expires, the quorum MUST be reformed.
4. Quorum Caching: Nodes SHOULD cache the quorum set for a given key
to avoid re-computation. Cache entries MUST be invalidated on
quorum expiry or when the node's routing table changes
significantly (e.g., after joining or leaving the overlay).
2.1.3.7.2. Byzantine Fault Tolerance
The Global Directory Quorum operates under the following fault
tolerance assumptions:
* BFT Assumption: The quorum tolerates up to f = 2 Byzantine faults
among the 7 quorum nodes. This is consistent with the standard
BFT bound of n = 3f + 1 (i.e., 7 >= 3*2 + 1 = 7).
* Failure Modes: Byzantine failures include:
- Malicious nodes submitting false PoM tickets.
- Nodes colluding to suppress valid PoM tickets.
- Nodes equivocating (signing conflicting validation results).
- Nodes failing to respond within the timeout window.
Gebauer Expires 29 January 2027 [Page 7]
Internet-Draft IACP - DHT July 2026
* Honest Node Assumption: The protocol assumes that at least f + 1 =
3 nodes in any quorum are honest (non-Byzantine). This is the
minimum required to achieve consensus.
* Stronger Assumptions: Applications requiring higher fault
tolerance MAY increase the quorum size n to support larger f. The
relationship n >= 3f + 1 MUST be maintained.
2.1.3.7.3. PoM Ticket Validation Protocol
A PoM ticket is validated by the Global Directory Quorum through the
following protocol:
1. Ticket Submission: The accusing node submits a PoM ticket (Type
0x18) to the quorum. The ticket MUST be sent to all 7 quorum
nodes. The submission includes the PoM_Ticket structure.
2. Individual Validation (Phase 1): Each quorum node independently
validates the PoM ticket:
a. Signature Verification: Verify that Signature_A and
Signature_B are valid Ed25519 signatures against the Target_EID
public key.
b. Structural Check: Verify that Header_Fragment_A and
Header_Fragment_B are structurally non-identical.
c. Freshness Check: Verify that the Timestamp is within T_fresh
= 5 minutes of the node's current time. Nodes MUST reject
tickets with stale timestamps.
d. Double-Spending Check: Verify that the Target_EID is not
already in STATE_SLASHED.
If any validation check fails, the node MUST respond with a
POM_VALIDATION_REJECT message indicating the failure reason.
3. Voting Phase (Phase 2): Each node that successfully validates the
PoM ticket sends a POM_VALIDATION_ACCEPT message to all other
quorum nodes. The message MUST include the node's signature:
POM_VALIDATION_ACCEPT = {
Ticket_Hash: SHA-256(PoM_Ticket),
EID_Validator: EID of the validating node,
Timestamp: Current time,
Signature: Sign_Ed25519(Private_Key_Validator,
Ticket_Hash || EID_Validator || Timestamp)
}
Gebauer Expires 29 January 2027 [Page 8]
Internet-Draft IACP - DHT July 2026
1. Consensus Phase (Phase 3): Each node collects validation
messages. Consensus is reached when at least m = 4 out of 7
nodes have sent POM_VALIDATION_ACCEPT for the same ticket hash.
The threshold m = ceil((n + 1) / 2) = ceil(8/2) = 4 ensures a
simple majority.
2. Commit Phase (Phase 4): Upon reaching consensus, each node:
a. Commits the PoM ticket to its local ledger. b. Triggers the
2PSE process, transitioning the Target_EID to STATE_CHALLENGED.
c. Propagates the committed PoM ticket to the DHT overlay.
The committing node sends a POM_COMMIT message to the quorum:
POM_COMMIT = {
Ticket_Hash: SHA-256(PoM_Ticket),
Consensus_Proof: [POM_VALIDATION_ACCEPT_1, ..., POM_VALIDATION_ACCEPT_m],
EID_Committer: EID of the committing node,
Signature: Sign_Ed25519(Private_Key_Committer, Ticket_Hash || Consensus_Proof)
}
1. Timeout: If the quorum does not reach consensus within
T_consensus = 30 seconds, the ticket validation fails. The
accusing node MAY retry the submission after an exponential
backoff (T_base = 2 seconds, T_max = 60 seconds).
2.1.3.7.4. Network Partition and Split-Brain Handling
Network partitions (split-brain scenarios) are handled as follows:
1. Partition Detection: Nodes detect partitions by monitoring quorum
member responsiveness. If a node fails to receive responses from
at least m = 4 quorum members within T_heartbeat = 10 seconds,
the node assumes a partition exists.
2. Quorum Reform: During a partition, the node MUST NOT initiate new
PoM validations. Existing validation attempts continue.
3. Conflict Resolution: If two partitions independently validate
conflicting PoM tickets, the following rules apply:
a. Larger Partition: The partition with the larger number of
quorum nodes (>= 4) takes precedence. The smaller partition MUST
discard its validation results and synchronize with the larger
partition upon reconnection.
Gebauer Expires 29 January 2027 [Page 9]
Internet-Draft IACP - DHT July 2026
b. Tie Handling: If both partitions have exactly 3 nodes (a 3-4
split), no consensus is possible. All validation attempts in
both partitions MUST be aborted. The target EID remains in
STATE_NOMINAL. The accusing node MUST retry after the partition
resolves.
c. Rollback: When a partition resolves, nodes in the smaller
partition MUST roll back any state changes made during the
partition (e.g., PoM ticket commits) and synchronize with the
larger partition's state.
4. Conflict Log: All partition events, including aborted validations
and rollback decisions, MUST be logged for audit purposes. The
log MUST include timestamps, partition node sets, and the
affected target EIDs.
5. Recovery: After partition resolution, nodes SHOULD wait
T_recovery = 60 seconds before initiating new PoM validations to
allow the overlay to stabilize.
2.1.3.7.5. Quorum Member Liveness
To ensure quorum availability, the following liveness rules apply:
1. Heartbeat: Each quorum member MUST send a QUORUM_HEARTBEAT
message to all other quorum members every T_heartbeat = 10
seconds.
2. Failure Detection: If a node misses T_heartbeat_fail = 3
consecutive heartbeats (30 seconds), it is considered failed.
3. Member Replacement: When a quorum member is considered failed,
the remaining nodes MUST replace it. The replacement is selected
from the k = 20 candidate set as the next node in the permuted
list that is not already in the quorum.
4. Quorum Stability: The quorum SHOULD maintain n = 7 nodes at all
times. Replacement MUST occur within T_replace = 60 seconds of
failure detection.
2.1.3.8. Routing Table Maintenance
Each node maintains a routing table of k-buckets organized by XOR
distance from its own Node ID. Buckets are structured as follows:
* Bucket 0: peers with a shared prefix length of 255 bits (closest)
* Bucket i: peers with a shared prefix length of (255 - i) bits
Gebauer Expires 29 January 2027 [Page 10]
Internet-Draft IACP - DHT July 2026
* Maximum bucket size: k = 20
When a bucket is full and a new peer is discovered, the node pings
the least-recently-seen peer in the bucket. If the peer responds,
the new peer is not added. If the peer does not respond, it is
evicted and the new peer is added.
When a node's routing table is initialized, it contains a single
bucket covering the entire 256-bit identifier space (bucket 0). As
the node learns about more peers, the bucket splits according to the
following algorithm:
* The node maintains a list of buckets, each covering a contiguous
range of the identifier space.
* When a bucket exceeds its maximum size k = 20, the node splits the
bucket into two new buckets.
* The split point is determined by the node's own Node ID: the
bucket is divided at the bit position where the node's ID differs
from the bucket's range midpoint.
* The left bucket (closer to 0x0000...0000) and right bucket (closer
to 0xFFFF...FFFF) each cover half of the original range.
* The node redistributes the existing peers from the original bucket
into the two new buckets based on their XOR distance to the node's
own ID.
* Buckets that do not contain the node's own ID MAY be split
further, but only if they contain at least k + 1 peers.
The splitting process continues until the routing table contains
buckets for each prefix length where the node has at least one peer.
To maintain bucket freshness, each bucket entry includes a timestamp
of the last successful contact with the peer. The least-recently-
seen peer is determined by comparing these timestamps. When a bucket
is full and a new peer is discovered, the node pings the least-
recently-seen peer in the bucket. If the peer responds within T_ping
= 1 second, the node updates the peer's timestamp to the current
time, the new peer is not added, and the node MAY add the new peer to
a replacement cache. If the peer does not respond within T_ping, the
node removes the stale peer from the bucket, adds the new peer to the
bucket with the current timestamp, and if the replacement cache
contains peers for this bucket, the node SHOULD attempt to add them
as well.
Gebauer Expires 29 January 2027 [Page 11]
Internet-Draft IACP - DHT July 2026
To detect churn and evict stale entries, nodes MUST periodically
refresh each bucket:
* The refresh interval is T_refresh = 5 minutes.
* For each bucket, the node selects the least-recently-seen peer and
sends a ping.
* If the peer responds, the timestamp is updated.
* If the peer does not respond, it is evicted and replaced by the
most recent peer from the replacement cache, if available.
* If the replacement cache is empty, the bucket is left with one
fewer entry.
* The refresh process is spread across the T_refresh interval to
avoid bursts of network traffic. The node SHOULD refresh buckets
in random order.
The following limits apply to the routing table:
* Maximum buckets: 256 (one per bit prefix length)
* Maximum bucket size: k = 20
* Maximum total routing table entries: 256 * 20 = 5120 entries
In practice, a node will only have entries in buckets where it has
discovered peers. The total number of entries is typically O(log n)
where n is the number of nodes in the overlay, which is around 160
entries for a network of 2^160 nodes. Nodes SHOULD implement a
maximum routing table size of 5120 entries. If this limit is
exceeded, the node SHOULD evict the least-recently-seen peers from
the least-relevant buckets (those furthest from the node's own ID).
Each node maintains a replacement cache for each bucket. The
replacement cache stores peers that were discovered but could not be
added because the bucket was full:
* Cache size: C = 10 entries per bucket (RECOMMENDED).
* Cache entries have a TTL of T_cache = 1 hour.
* When a peer is evicted from a bucket, the most recent entry from
the replacement cache is promoted to the bucket.
Gebauer Expires 29 January 2027 [Page 12]
Internet-Draft IACP - DHT July 2026
* When a new peer is discovered and the bucket is full, the peer is
added to the replacement cache if it is not already present.
The replacement cache prevents the loss of potential routing
information when buckets are full.
2.1.3.9. Replication and Redundancy
To ensure availability under churn, each key-value pair (EID-to-
locator mapping or Forwarding Ticket) MUST be stored on the k closest
nodes to the key, where k = 20. Additionally:
* Replication Factor: r = 7 (the key is stored on the 7 closest
nodes).
* Republish Interval: Nodes MUST republish their own mappings every
T_republish = 24 hours.
* Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes
MUST refresh a mapping before expiration by re-issuing the STORE
operation.
The replication set for a key is determined as follows:
* The node computes the key's SHA-256 hash (for namespace mappings)
or uses the EID directly (for EID-to-locator mappings).
* The node performs a FIND_NODE lookup to identify the k = 20
closest nodes to the key.
* The replication set is the first r = 7 nodes from this list.
* The key-value pair is stored on all r nodes.
To ensure redundancy, each replication node MUST store the key-value
pair for T_expire = 48 hours. If a replication node fails, the
remaining nodes SHOULD replicate the key to a replacement node from
the k = 20 candidate set.
To prevent accumulation of stale mappings:
* Each node MUST periodically (every T_prune = 1 hour) scan its
local DHT storage for entries with expired TTLs.
* Entries older than T_expire = 48 hours MUST be deleted.
* Entries with TTL less than T_expire_alert = 6 hours SHOULD trigger
a refresh request to the originating node.
Gebauer Expires 29 January 2027 [Page 13]
Internet-Draft IACP - DHT July 2026
* If the originating node does not refresh the entry within
T_expire, the entry is deleted.
Nodes SHOULD implement a lazy deletion strategy: entries are marked
as stale and deleted on access rather than during periodic scans, to
reduce CPU overhead.
2.1.3.10. Lookup Operations
Lookups for an EID coordinate follow the standard Kademlia iterative
lookup:
1. The initiating node selects alpha = 3 nodes from its routing
table closest to the target key.
2. It sends parallel FIND_NODE requests to these nodes.
3. Each responding node returns the k closest nodes it knows to the
target key.
4. The initiator updates its routing table with the responses and
continues the iterative process until it has contacted the
closest nodes or until no closer nodes are found.
The lookup is considered successful if the target key is found or if
the closest nodes report that the key does not exist.
2.1.3.11. Anti-Eclipse and Sybil Protections
To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces
the following:
1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which
already require Proof-of-Work for registration. This makes Sybil
generation computationally expensive.
2. Randomized Bucket Selection: When selecting nodes for lookup
operations, the initiator SHOULD include a random selection from
the k-bucket in addition to the closest nodes to prevent an
attacker from monopolizing a bucket.
3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5
minutes) ping the least-recently-seen peer in each bucket to
detect churn and evict stale entries.
Gebauer Expires 29 January 2027 [Page 14]
Internet-Draft IACP - DHT July 2026
2.1.3.12. Lookup Flow
The iterative lookup process follows this flow:
+-------------+ +-------------+ +-------------+
| Initiator | | Node A | | Node B |
+-------------+ +-------------+ +-------------+
| | |
| 1. FIND_NODE | |
|------------------>| |
| | |
| 2. RETURN k | |
|<------------------| |
| | |
| 3. FIND_NODE | |
|-------------------------------------->|
| | |
| 4. RETURN k | |
|<--------------------------------------|
| | |
v (Continue until closest nodes found) v
+-------------+ +-------------+ +-------------+
| Result | | Closest | | Closest |
| Found | | Node Set | | Node Set |
+-------------+ +-------------+ +-------------+
2.1.3.13. Local Caching
To reduce DHT lookup latency and network overhead, nodes SHOULD
maintain a local cache of recently resolved EID-to-locator mappings
and Forwarding Tickets.
The local cache is a key-value store with the following structure:
* Key: SHA-256(EID) (for EID-to-locator mappings) or the storage key
(for Forwarding Tickets)
* Value: (IP address, Port, Generation Counter, Timestamp, TTL)
* TTL: T_cache = 300 seconds (5 minutes) for EID-to-locator
mappings, T_forward = 7 days for Forwarding Tickets
When a node needs to resolve an EID:
1. The node checks the local cache for the key SHA-256(EID).
2. If the entry exists and has not expired (Timestamp + TTL >
current_time):
Gebauer Expires 29 January 2027 [Page 15]
Internet-Draft IACP - DHT July 2026
* The node returns the cached mapping.
* The node updates the entry's timestamp to the current time.
3. If the entry does not exist or has expired:
* The node performs a DHT lookup.
* If the lookup succeeds, the node stores the result in the
cache with TTL = 300 seconds.
The local cache MUST be invalidated under the following conditions:
* The node receives a MIGRATION_VECTOR for the EID with a higher
Generation Counter.
* The node receives a REVOCATION_SUBMIT for the EID.
* The node detects that the cached IP address is unreachable (ping
fails).
* The cache entry's TTL expires.
When a cache entry is invalidated, the node MUST remove the entry
from the cache and perform a fresh DHT lookup on the next request.
The local cache SHOULD be limited to C_max = 10000 entries to prevent
memory exhaustion. When the cache exceeds this limit, the node
SHOULD evict the least-recently-used (LRU) entries first. Nodes in
resource-constrained environments (e.g., IoT devices) SHOULD use a
smaller cache size (e.g., C_max = 1000 entries) to reduce memory
consumption.
2.1.3.14. Churn Handling
The DHT overlay MUST handle node churn (nodes joining, leaving, and
failing) gracefully.
When a node joins the DHT overlay:
1. The node obtains bootstrap contact.
2. The node performs a FIND_NODE lookup for its own Node ID to
populate its routing table.
3. The node sends a STORE operation to the replication set for its
own EID-to-locator mapping.
Gebauer Expires 29 January 2027 [Page 16]
Internet-Draft IACP - DHT July 2026
4. The node begins participating in routing and query forwarding.
When a node leaves the DHT overlay gracefully:
* The node SHOULD send a LEAVE message to the replication nodes
storing its key-value pairs.
* The node SHOULD store its key-value pairs on replacement nodes
before leaving.
* The node SHOULD send a PSS_TEARDOWN to terminate all active PSS
sessions.
If a node leaves without notice (crash or network partition), the
replication set must handle the failure.
Nodes detect failures using the following mechanisms:
* PING/PONG: Nodes periodically ping peers in their routing table.
If a peer fails to respond to T_ping_fail = 3 consecutive pings
(each separated by T_ping_interval = 1 second), the peer is
considered failed.
* Quorum Heartbeat: Quorum members send heartbeats every T_heartbeat
= 10 seconds. Failure to receive 3 consecutive heartbeats
indicates a failure.
* Passive Detection: If a node fails to respond to FIND_NODE or
STORE requests, it is considered potentially failed. The
requesting node SHOULD retry with a different node.
When a node in the replication set fails:
1. The remaining replication nodes detect the failure via heartbeat.
2. The remaining nodes select a replacement from the k = 20
candidate set.
3. The replacement node is the next node in the permuted list that
is not already in the quorum and is reachable.
4. The remaining nodes replicate all key-value pairs for the
affected key to the replacement node.
5. The quorum is restored to n = 7 nodes.
When a network partition occurs:
Gebauer Expires 29 January 2027 [Page 17]
Internet-Draft IACP - DHT July 2026
* Partition Detection: Nodes detect partitions by monitoring quorum
member responsiveness. If a node fails to receive responses from
at least m = 4 quorum members within T_heartbeat = 10 seconds, the
node assumes a partition exists.
* During a partition, nodes MUST NOT initiate new PoM validations.
* If two partitions independently commit conflicting state, the
larger partition (>= 4 nodes) takes precedence.
* After partition resolution, nodes in the smaller partition MUST
roll back any state changes made during the partition and
synchronize with the larger partition.
* Nodes SHOULD wait T_recovery = 60 seconds after partition
resolution before initiating new operations.
The DHT overlay is designed to handle churn rates of up to 10% of
nodes per hour without significant performance degradation. The
following factors contribute to churn resilience:
* Replication factor r = 7 ensures that data remains available even
if multiple replication nodes fail.
* Bucket refresh (T_refresh = 5 minutes) detects and evicts stale
peers quickly.
* Replacement cache ensures that routing table entries are replaced
efficiently.
* Local cache reduces DHT lookup frequency during churn events.
2.1.3.15. DHT Message Types
The following DHT-specific message types are defined and used
internally by the DHT overlay. They are not exposed to the
application layer. The wire formats for these message types are
defined in Appendix A.
Gebauer Expires 29 January 2027 [Page 18]
Internet-Draft IACP - DHT July 2026
| Type | Name |
|------|--------------------|
| 0x3A | DHT_FIND_NODE |
| 0x3B | DHT_FIND_NODE_RESP |
| 0x3C | DHT_STORE |
| 0x3D | DHT_STORE_ACK |
| 0x3E | DHT_PING |
| 0x3F | DHT_PONG |
| Type | Description |
|------|--------------------------------------------------|
| 0x3A | Find the k closest nodes to a target key |
| 0x3B | Response to FIND_NODE with list of closest nodes |
| 0x3C | Store a key-value pair on a replication node |
| 0x3D | Acknowledgment of STORE operation |
| 0x3E | Ping a peer to check liveness |
| 0x3F | Response to PING |
Additionally, each node in the Node List is encoded as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node IP [16 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. Namespace Registration and Curation
2.2.1. Root Namespace Registration
Root namespace allocation maps human-readable, deterministic
alphanumeric tags directly to target resource coordinates inside the
DHT. To prevent arbitrary domain-squatting, sybil-based lookup
pollution, and coordinate collision, registration requires an initial
un-spendable burn-allocation fee or verified resource escrow
contract.
Gebauer Expires 29 January 2027 [Page 19]
Internet-Draft IACP - DHT July 2026
A root namespace record binds a unique, permanent cryptographic
curation certificate containing a designated public key authorized to
issue modifications, updates, or cryptographic revocations.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace Alphanumeric String Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cryptographic Curation Public Key (Ed25519) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Escrow Allocation Index Block |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.2. Sub-Namespace Delegation
The authorized root custodian public key can sign delegation tokens
to authorize downstream sub-namespaces. A valid delegation consists
of a cryptographic path chain evaluated dynamically during resource
lookups.
+------------------+ Signed Delegation +---------------------+
| Root Namespace | ------------------------> | Sub-Namespace Token |
| [Root Ed25519] | | [Sub-Node Ed25519] |
+------------------+ +---------------------+
|
v
+---------------------+
| Terminal Target EID |
+---------------------+
Lookups resolving sub-namespaces MUST process the complete
authorization chain from the root key down to the terminal record.
Any missing signature, expired validation window, or invalid
alignment with the parent path constraints breaks the validation path
and causes resolution to abort.
2.3. Proof-of-Work and Reputation-Based Access Control
Gebauer Expires 29 January 2027 [Page 20]
Internet-Draft IACP - DHT July 2026
2.3.1. Dynamic PoW Difficulty
To defend the DHT routing network from distributed denial-of-service
(DDoS) vectors and lookup depletion attacks, directory mutations and
intensive lookup queries require a valid Proof-of-Work (PoW) token
header based on Hashcash.
The targeted leading-zero bit difficulty coefficient D_req adjusts
dynamically depending on the processing load, lookup queue latency,
and incoming query volume of individual directory zones.
D_req = D_base + floor(gamma * (Queue_Current / Queue_Max))
Where D_base represents the baseline minimum bit difficulty, gamma
represents the scalar operational multiplier, and Queue_Current
measures the active buffer depth of the handling node. Lookups
submitted with an insufficient trailing zero bitmask are dropped at
the ingress interface without allocating resources or memory space.
2.3.2. Access Tickets and Joint Liability
Validated transactions give the requester an implicit short-lived
routing credit via an Access Ticket. If an internal Autonomous Agent
Instance (AAI) generates malicious control plane activity, the
hosting infrastructure and the individual peer entity are held under
joint liability.
+------------------------+ +-----------------------+
| Hosting Provider / |<= Joint Liability =>| Malicious Autonomous |
| Parent LL-Entity | | Agent Instance (AAI) |
+------------------------+ +-----------------------+
| |
v v
Slashing of Host Collateral EID Key Revocation List
If an individual agent breaks wire protocols, the network scales back
the performance tracking matrix of the entire network segment or host
infrastructure layer, creating a strong structural incentive for
local platforms to isolate misbehaving processes.
2.4. Anti-Abuse Mechanisms
Gebauer Expires 29 January 2027 [Page 21]
Internet-Draft IACP - DHT July 2026
2.4.1. Token-Bucket Filters and Rate Limiting
Ingress packets undergo rate-limiting enforcement via an independent
Token-Bucket algorithmic state machine integrated inside the
transport layer. The configuration uses two static parameters:
maximum bucket capacity (C_max) and token replenishment rate
(R_repl).
Tokens_Available = min(C_max, Tokens_Previous + (Delta_Time *
R_repl))
Each transaction consumes tokens based on the lookup size and
complexity. If Tokens_Available falls below the required request
cost, the packet is discarded, and the node returns an explicit error
payload to trigger transport-level backoff.
2.4.2. Autonomous Circuit Breakers
When a target zone or specific peer coordinate experiences sudden
inbound traffic anomalies exceeding standard operation limits by
orders of magnitude, local routing nodes autonomously change state to
prevent cascading memory depletion.
+--------------+ Anomalous Load > Threshold +--------------+
| STATE_OPEN | -------------------------------> | STATE_TRIPPED|
+--------------+ +--------------+
^ |
| Cooldown + Load Normal |
+-------------------------------------------------+
While in STATE_TRIPPED, nodes refuse all standard lookup mutations
and enter an aggressive caching enforcement mode. The node drops
unauthenticated requests immediately, allowing the transport stack to
bypass costly parsing loops and handle targeted resource exhaustion
at wire speeds.
2.5. Proof of Malfeasance (PoM) and Slashing
2.5.1. PoM Ticket Specification
A Proof of Malfeasance (PoM) ticket contains clear cryptographic
proof that a node or agent committed protocol violations, such as
double-signing contradictory routing states, deploying conflicting
mapping epochs, or fabricating directory routing steps.
PROOF_OF_MAL:
Gebauer Expires 29 January 2027 [Page 22]
Internet-Draft IACP - DHT July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Offense Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Malicious Node Identity (EID) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest A |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest B |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Accusing Node Cryptographic Signature |
| [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ticket must explicitly contain both conflicting signed messages
to allow independent verification by any peer executing standard
verification routines without relying on a central authority.
2.5.1.1. Timestamp Synchronization
The PoM_Ticket structure includes a Timestamp field marked as
"Cluster-synchronized verification time". This subsection specifies
how nodes achieve and maintain the required clock synchronization.
The Timestamp field MUST represent the current time in UTC as a
64-bit UNIX timestamp (seconds since 1970-01-01T00:00:00Z). Nodes
MUST ensure that their local clocks are synchronized to within a
bounded drift of the global time reference.
2.5.1.1.1. Primary Synchronization Mechanism: NTP
Nodes MUST implement Network Time Protocol (NTP) [RFC5905] or a
successor standard (e.g., NTS [RFC8915]) for clock synchronization.
The following requirements apply:
Gebauer Expires 29 January 2027 [Page 23]
Internet-Draft IACP - DHT July 2026
1. NTP Pool: Nodes SHOULD use a diverse set of NTP servers. The
RECOMMENDED minimum is 4 servers from different administrative
domains to reduce the risk of coordinated time manipulation.
2. Synchronization Interval: Nodes MUST synchronize their clocks at
least once every T_sync = 60 seconds while online.
3. Drift Tolerance: The acceptable clock drift between any two nodes
in the DHT overlay is T_drift = 5 seconds. NTP implementations
MUST maintain accuracy within this bound.
4. Fallback Servers: Nodes SHOULD maintain a list of at least 2
fallback NTP servers in case the primary servers are unreachable.
2.5.1.1.2. Alternative Synchronization Mechanisms
For environments where NTP is unavailable or undesirable, nodes MAY
use alternative synchronization mechanisms:
1. Precision Time Protocol (PTP) [IEEE1588]: For networks with
hardware timestamping support, PTP provides higher accuracy (sub-
microsecond) than NTP.
2. GPS/GNSS: For nodes with GPS receivers, GPS time provides a
highly accurate global time reference.
3. Blockchain Timestamping: Nodes in a blockchain-integrated
deployment MAY use block timestamps as a reference. However,
block timestamps are only advisory (per [RFC6962] Section 2.1)
and MUST NOT be the sole synchronization source.
4. Manual Configuration: As a last resort, operators MAY manually
configure the system time. This is NOT RECOMMENDED for
production deployments.
Regardless of the mechanism used, nodes MUST maintain the T_drift = 5
seconds accuracy bound.
2.5.1.1.3. Time Validation in PoM Ticket Processing
When a quorum node validates a PoM ticket, it MUST perform the
following time-related checks:
1. Absolute Freshness: The Timestamp MUST be within T_fresh = 5
minutes of the node's current time. Tickets with timestamps
older than T_fresh MUST be rejected.
Gebauer Expires 29 January 2027 [Page 24]
Internet-Draft IACP - DHT July 2026
2. Clock Drift Compensation: The node MAY apply a drift compensation
factor of up to T_drift = 5 seconds when evaluating the freshness
of a ticket. This compensates for minor synchronization
differences between nodes.
3. Replay Prevention: If a ticket with the same Timestamp and
Target_EID has been seen within the last T_replay = 10 minutes,
the node MUST reject the ticket as a replay attempt.
4. Monotonic Sequence Check: The node MUST verify that the
Sequence_Number in the ticket is strictly greater than the last
known sequence number for the Target_EID. This prevents
reordering attacks even if timestamps are close.
2.5.1.1.4. Handling Synchronization Failures
If a node cannot synchronize its clock within T_drift = 5 seconds for
more than T_sync_fail = 10 minutes, the following rules apply:
1. Quorum Participation: The node MUST NOT participate in PoM ticket
validation until synchronization is restored. It SHOULD respond
with a POM_VALIDATION_REJECT (reason: CLOCK_UNSYNCHRONIZED) to
any validation requests.
2. Degraded Operation: The node MAY continue to forward packets and
participate in routing, but MUST mark its state as
CLOCK_UNSYNCHRONIZED in its DHT advertisements.
3. Recovery: Upon successful resynchronization, the node MUST wait
T_recovery = 5 minutes before rejoining the quorum to allow its
clock to stabilize.
4. Alerting: The node SHOULD generate an alert to the operator when
synchronization fails.
2.5.1.1.5. Offline Node Timestamp Handling
Nodes that operate offline for extended periods (e.g., mobile agents)
MAY use the following fallback:
1. Last Known Time: The node uses the last known synchronized time
plus the elapsed time since synchronization (measured by the
node's local oscillator).
2. Bounded Drift: The node MUST assume a worst-case drift of
T_drift_offline = 1 second per hour of offline operation.
Gebauer Expires 29 January 2027 [Page 25]
Internet-Draft IACP - DHT July 2026
3. Freshness Check at Reconnection: Upon reconnection, the node MUST
synchronize its clock before submitting any PoM tickets. The
node MUST discard any tickets generated during the offline period
that exceed T_fresh = 5 minutes.
4. Trust Reduction: Nodes that have been offline for more than
T_offline_max = 24 hours SHOULD be treated as less trustworthy
and SHOULD be subject to escalated PoW requirements until they
have been online for T_online_stable = 1 hour.
2.5.1.1.6. Normative Notes
The timestamp synchronization requirements in this section are
normative. Conforming IACP implementations:
* MUST implement NTP [RFC5905] or provide equivalent synchronization
accuracy (T_drift <= 5 seconds).
* MUST validate timestamps according to the rules in this section.
* MUST handle synchronization failures according to the rules in
this section.
2.5.1.2. PoM Ticket Canonicalization and Semantics
A Proof of Malfeasance (PoM) ticket relies on the comparison of two
cryptographically signed messages to detect equivocation. This
section defines:
1. Which messages are subject to PoM verification.
2. How messages are canonicalized for comparison.
3. What semantic conditions constitute a valid PoM.
2.5.1.2.1. Canonicalization Target: The Signed Payload
For the purposes of PoM verification, the "message" that is signed is
defined as the complete IACP control frame payload for the following
message types:
* ERP_REGISTER (Type 0x15)
* MIGRATION_VECTOR (Type 0x17)
* ERP_EVOLVE (Type 0x16)
* Any message that modifies the EID-to-locator mapping
Gebauer Expires 29 January 2027 [Page 26]
Internet-Draft IACP - DHT July 2026
The canonicalization process MUST include all fields of these
messages except:
* The Signature field itself (it is self-referential)
* Timestamp fields (they are not part of the signed payload)
* Nonce fields (they are not part of the signed payload)
All other fields, including EID, IP address, Generation Counter, and
Application Digest, are included in the canonicalized message.
2.5.1.2.2. Canonicalization Format
The canonicalization format depends on the message serialization:
1. Binary Messages (e.g., ERP_REGISTER, MIGRATION_VECTOR): The
message is canonicalized as the concatenation of all fields in
the order they appear in the wire format, excluding the signature
field. The length of each field is determined by its type.
2. JSON Messages (e.g., Trust Anchor Documents): The message is
canonicalized using JSON Canonicalization Scheme (JCS) [RFC8785].
3. CBOR Messages: The message is canonicalized using Canonical CBOR
as defined in RFC 8949 Section 3.9.
The canonicalized representation is a byte string. The SHA-256 hash
of this byte string is used as the message digest in the PoM ticket.
2.5.1.2.3. Semantic Fields for PoM Verification
The following fields are considered semantically relevant for PoM
verification:
| Field | Message Types |
|--------------------|-----------------------------------|
| Source_EID | All |
| Current_IP | ERP_REGISTER, MIGRATION_VECTOR |
| Generation_Counter | ERP_REGISTER, MIGRATION_VECTOR |
| Current_App_Digest | ERP_EVOLVE |
| Field | Semantics |
|--------------------|-----------------------------------|
| Source_EID | The identity of the signer |
| Current_IP | The claimed transport locator |
| Generation_Counter | The epoch of the mapping |
| Current_App_Digest | The software version |
Gebauer Expires 29 January 2027 [Page 27]
Internet-Draft IACP - DHT July 2026
Two messages are considered "conflicting" if:
1. They are signed by the same EID.
2. They have the same Generation_Counter (same logical epoch).
3. They differ in at least one semantically relevant field.
Messages with different Generation_Counter values are NOT considered
conflicting (they represent legitimate state evolution). Messages
with the same Generation_Counter but differing in non-semantic fields
(e.g., TTL, Nonce) are NOT considered conflicting.
2.5.1.2.4. PoM Verification Procedure
The Global Directory Quorum validates a PoM ticket as follows:
1. Extract Digests: Extract Digest_A and Digest_B from the PoM
ticket. Each digest is the SHA-256 hash of a canonicalized
signed message.
2. Verify Signatures: Verify that Signature_A and Signature_B are
valid against Target_EID and cover Digest_A and Digest_B
respectively.
3. Retrieve Original Messages: Retrieve the original messages (or
their canonicalized forms) from the network ledger or from the
ticket itself. The ticket MUST include enough information to
locate or reconstruct the original messages.
4. Canonicalize: Re-canonicalize the original messages using the
procedure described above.
5. Hash Comparison: Compute SHA-256 of the canonicalized messages
and verify they match Digest_A and Digest_B.
6. Semantic Comparison: Compare the semantically relevant fields of
the two messages.
7. Decision: If the messages are signed by the same EID, have the
same Generation_Counter, and differ in at least one semantically
relevant field, the PoM ticket is valid. Otherwise, it is
invalid.
2.5.1.2.5. Example: Legitimate vs. Malicious Updates
Legitimate IP Change (MIGRATION_VECTOR):
Gebauer Expires 29 January 2027 [Page 28]
Internet-Draft IACP - DHT July 2026
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X,
IP = 192.0.2.2, Gen = 6 }
Gen differs -> NOT a PoM. This is legitimate mobility.
Equivocation (Malicious):
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X,
IP = 192.0.2.2, Gen = 5 }
Gen same, IP differs -> PoM VALID. This is equivocation.
Same State (No Violation):
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5, TTL = 300 } Message_B:
{ EID = X, IP = 192.0.2.1, Gen = 5, TTL = 600 }
Gen same, IP same, only TTL differs -> NOT a PoM.
2.5.1.3. Decentralized PoM Count Consistency
The IACP DHT overlay maintains a decentralized, eventually consistent
count of PoM tickets per EID to enforce the slashing threshold
(PoM_Count >= 3 within a rolling 24-hour window). This section
specifies how the PoM_Count is maintained, synchronized, and
reconciled across the DHT overlay.
2.5.1.3.1. Local PoM Ledger
Each node in the DHT overlay maintains a local PoM ledger containing
PoM tickets that the node has observed and validated. The ledger
consists of the following fields per entry:
PoM_Ledger_Entry = {
Target_EID: The EID of the accused entity (32 bytes),
Ticket_Hash: SHA-256 of the PoM ticket (32 bytes),
Timestamp: UNIX timestamp of ticket validation (8 bytes),
Validator_EID: EID of the validating node (32 bytes),
Quorum_Proof: Reference to quorum consensus (variable),
Status: VALID, CHALLENGED, or SLASHED (1 byte)
}
The local PoM ledger is maintained for a minimum of T_ledger = 30
days to ensure that historical data is available for audits and for
nodes that have been offline.
Gebauer Expires 29 January 2027 [Page 29]
Internet-Draft IACP - DHT July 2026
2.5.1.3.2. PoM Count Replication
The PoM_Count for a given EID is replicated in the DHT overlay to
ensure availability and consistency:
1. Storage Key: The PoM ledger entries for an EID are stored in the
DHT under the key SHA-256("pom:" || Target_EID).
2. Replication Factor: PoM ledger entries are replicated with
redundancy factor r = 7 to ensure availability under churn.
3. Replication Nodes: The r closest nodes to the storage key (SHA-
256("pom:" || Target_EID)) are responsible for storing and
replicating the PoM ledger entries.
4. Merkle Tree Structure: To enable efficient synchronization, PoM
ledger entries are organized as a Merkle tree. The root hash is
stored in the DHT and is updated whenever a new entry is added.
The PoM_Count for an EID is calculated as the number of VALID PoM
tickets in the ledger that fall within the rolling 24-hour window:
PoM_Count(EID, t) = count({ entry in PoM_Ledger(EID) |
entry.Status = VALID AND
entry.Timestamp > (t - 24h) })
2.5.1.3.3. PoM Ticket Publishing and Ledger Update
When a PoM ticket is validated by the Global Directory Quorum, the
committing node MUST update the PoM ledger:
1. Local Update: The node adds the validated PoM ticket to its local
PoM ledger with Status = VALID and the current timestamp.
2. DHT Propagation: The node publishes the updated PoM ledger entry
to the DHT under SHA-256("pom:" || Target_EID). The publication
uses a DHT_POM_UPDATE message:
Gebauer Expires 29 January 2027 [Page 30]
Internet-Draft IACP - DHT July 2026
DHT_POM_UPDATE = {
Target_EID: The EID of the accused entity (32 bytes),
Ticket_Hash: SHA-256 of the PoM ticket (32 bytes),
Timestamp: UNIX timestamp of validation (8 bytes),
Validator_EID: EID of the validating node (32 bytes),
Quorum_Proof: Consensus proof (variable),
Merkle_Root_New: Updated Merkle tree root (32 bytes),
Signature: Sign_Ed25519(Private_Key_Validator,
Target_EID || Ticket_Hash ||
Timestamp || Merkle_Root_New)
}
1. Replication: The r replication nodes receive the DHT_POM_UPDATE,
verify the signature and quorum proof, and update their local
ledger copies.
2. Acknowledgment: Each replication node responds with a DHT_POM_ACK
message confirming receipt and successful update.
3. Conflict Resolution: If a replication node detects a conflict
(e.g., inconsistent Merkle root), it initiates a reconciliation
process.
2.5.1.3.4. PoM Ledger Reconciliation
To ensure consistency across the DHT overlay, PoM ledger entries are
reconciled periodically:
1. Merkle Root Comparison: Nodes periodically (every T_reconcile = 1
hour) compare their Merkle root for each EID with the other
replication nodes. If a discrepancy is found, the node initiates
a reconciliation.
2. Reconciliation Protocol: The node with the more complete ledger
(higher sequence number or larger Merkle tree) sends the missing
entries to the other nodes.
3. Conflict Handling: If two nodes have conflicting entries for the
same PoM ticket (e.g., one VALID, one CHALLENGED), the entry with
the higher consensus proof (more quorum signatures) takes
precedence.
4. Time-based Reconciliation: Nodes that have been offline for more
than T_offline = 1 hour MUST perform a full ledger
synchronization upon reconnection by requesting the full Merkle
tree from the closest replication node.
Gebauer Expires 29 January 2027 [Page 31]
Internet-Draft IACP - DHT July 2026
5. Lazy Reconciliation: Nodes MAY defer reconciliation of low-
priority EIDs (those with PoM_Count < 2) to reduce network
overhead.
2.5.1.3.5. Slashing Decision Consistency
The slashing decision (PoM_Count >= 3) MUST be made consistently
across the DHT overlay:
1. Threshold Check: The slashing decision is triggered only after a
PoM ticket has been validated by the Global Directory Quorum and
the updated PoM_Count is confirmed by at least m = 4 out of 7
replication nodes.
2. Consensus on Slashing: The Global Directory Quorum MUST reach
consensus on the slashing decision. The quorum nodes verify that
PoM_Count >= 3 by checking their local PoM ledgers and the
replicated ledger entries.
3. Slashing Commitment: Upon reaching consensus, the quorum nodes
transition the target EID to STATE_SLASHED and publish a
SLASH_COMMIT message to the DHT:
SLASH_COMMIT = {
Target_EID: The EID being slashed (32 bytes),
PoM_Count: The confirmed PoM count (1 byte),
Timestamp: UNIX timestamp of slashing (8 bytes),
Slashing_Reason: Reason code (4 bytes),
Consensus_Proof: [SLASH_VOTE_1, ..., SLASH_VOTE_m],
Signature: Sign_Ed25519(Private_Key_Committer,
Target_EID || PoM_Count ||
Timestamp || Consensus_Proof)
}
1. Propagation: The SLASH_COMMIT message is propagated to all nodes
in the DHT overlay. Nodes that receive this message MUST update
their local PoM ledger and mark the Target_EID as STATE_SLASHED.
2.5.1.3.6. Rolling Window Consistency
The rolling 24-hour window for PoM_Count calculation requires
consistent timestamps across the DHT overlay:
1. Timestamp Standardization: All PoM ticket timestamps MUST be
cluster-synchronized. Nodes that observe a timestamp discrepancy
greater than T_drift = 5 seconds SHOULD reject the PoM ticket.
Gebauer Expires 29 January 2027 [Page 32]
Internet-Draft IACP - DHT July 2026
2. Window Calculation: The rolling window is calculated as
(current_time - 24h) to current_time. Nodes MUST use their local
synchronized time for this calculation.
3. Sliding Window Maintenance: Nodes SHOULD periodically (every
T_window_maintenance = 1 hour) prune their local PoM ledger of
entries that are older than 24 hours to reduce storage overhead.
4. Window Check at Slashing: When evaluating PoM_Count for slashing,
nodes MUST exclude entries older than 24 hours to ensure that
only recent violations are considered.
2.5.1.3.7. Byzantine Behavior in PoM Counting
The following Byzantine failure modes are addressed:
1. Double-Counting: A malicious node might attempt to add the same
PoM ticket multiple times. The Merkle tree structure prevents
this, as each ticket hash is unique.
2. Count Inflation: A malicious node might attempt to forge PoM
tickets for a target EID. The quorum validation prevents this,
as forged tickets will not pass signature verification.
3. Count Suppression: A malicious replication node might attempt to
suppress valid PoM tickets. The replication factor r = 7 ensures
that at least m = 4 nodes are needed to suppress a ticket, making
this expensive.
4. Inconsistent Views: Different nodes might have different views of
the PoM_Count due to network partitions. The quorum-based
consensus mechanism ensures that slashing decisions are made only
when at least m = 4 nodes agree on the count.
2.5.1.3.8. Message Types for PoM Ledger
The following IACP message types are defined:
| Type | Name | Description |
|--------|--------------------|--------------------------------------|
| 0x33 | DHT_POM_UPDATE | Update PoM ledger entry in DHT |
| 0x34 | DHT_POM_ACK | Acknowledgment of PoM ledger update |
| 0x35 | SLASH_COMMIT | Commit slashing decision to DHT |
| 0x36 | SLASH_VOTE | Vote on slashing decision |
Gebauer Expires 29 January 2027 [Page 33]
Internet-Draft IACP - DHT July 2026
2.5.2. Two-Phase Slashing Escrow (2PSE)
To safeguard against malicious or erroneous accusations, the network
processes slashing actions using a strict two-phase challenge
framework.
+--------------------+ PoM Published +--------------------+
| STATE_NOMINAL | -----------------> | STATE_CHALLENGED |
+--------------------+ +--------------------+
|
Escrow Epoch Expires |
(No Valid Counter-Proof) |
v
+--------------------+
| STATE_SLASHED |
+--------------------+
1. Phase 1 (Escrow State): Upon receipt of a valid PoM ticket, the
target entity transitions into STATE_CHALLENGED. The node's
associated staking deposit or registration token is locked within
a secure escrow quarantine window for a fixed epoch block count.
2. Phase 2 (Execution State): If the challenged node cannot submit a
cryptographically valid counter-proof before the quarantine
window expires, the escrow balance is permanently burned, and the
node changes state to STATE_SLASHED.
2.5.3. Curator Quarantine and Decapitation
If a trusted root namespace curator node is flagged by a verified PoM
ticket, the protocol enforces immediate quarantine procedures. The
flagged node's authorization rights are suspended, and its assigned
DHT zones are temporarily managed by an uncompromised backup peer
quorum.
+-------------------------+ +-------------------------+
| Compromised Curator Node| | Backup Peer Quorum |
+-------------------------+ +-------------------------+
| State: SUSPENDED | | State: ACTIVE GOVERNANCE|
| Rights: REVOKED | | Action: Re-route Zone |
+-------------------------+ +-------------------------+
If the protocol violation is confirmed, the node undergoes total
network decapitation. Its long-term curation keys are added to a
decentralized revocation bloom filter, making all downstream
delegation signatures void across the network ecosystem.
Gebauer Expires 29 January 2027 [Page 34]
Internet-Draft IACP - DHT July 2026
2.5.4. Reputation Penalties
The reputation metric (Section 3.6.1) uses the following penalties:
* PoM Score Normalization: PoM_Score(t) = min(1.0, PoM_Count(t) / k)
with k = 5. This means that up to 5 PoM tickets are used to
normalize the score; beyond 5, the score is capped at 1.0.
* Decay Mechanism: PoM tickets older than 30 days are weighted with
a decay factor of 0.5 (i.e., their contribution to the reputation
score is halved). This ensures that older violations have less
impact on current reputation.
* Rehabilitation: A node with a reputation score below 0.3
(Section 3.6.2) MAY be rehabilitated after a cooldown period of 7
days without any new PoM tickets. The rehabilitation resets the
PoM_Count to 0.
2.6. Compromise Recovery and Hot-Docking
2.6.1. Migration Stream Serialization
The AAI operational state is serialized as a CBOR-encoded [RFC8949]
object containing the following fields:
* eid: The EID of the migrating agent (32 bytes)
* iat: The Instance Authentication Token (32 bytes)
* session_state: A CBOR map of active PSS session states
* ese_state: A CBOR map of Ephemeral State Endpoint data
* timestamp: A 64-bit UNIX timestamp
* sequence: A monotonically increasing sequence number
The serialized object is compressed using zlib (level 6) to reduce
transfer size.
2.6.2. Migration Stream Encryption
The serialized and compressed state is encrypted using AES-GCM-256
with a symmetric key derived from the EID's private key and the
backup host's public key:
K_migration = HKDF-SHA256(ECDH(Private_EID, Public_Backup), salt="",
info="IACP_MIGRATION_v1")
Gebauer Expires 29 January 2027 [Page 35]
Internet-Draft IACP - DHT July 2026
The encrypted migration stream includes a 12-byte AEAD nonce and a
16-byte authentication tag.
2.6.3. Forwarding Ticket Generation
After a successful migration, the compromised host generates a
Forwarding Ticket (Section 3.5) containing the new backup host's
network locator. The Forwarding Ticket is signed with the EID's
private key and stored in the DHT under KEY = SHA-256(EID).
In-flight packets destined for the old locator are redirected to the
new locator via the Forwarding Ticket. The old host's EID mapping is
invalidated after T_invalidate = 5 minutes.
2.6.4. Migration Flow
The hot-docking migration follows this sequence:
+------------------+ +-------------------+
| Compromised Host | | Backup Host |
| (Old A) | | (New B) |
+------------------+ +-------------------+
| |
| 1. Serialize AAI State (CBOR + zlib) |
| (eid, iat, session_state, ese_state) |
| |
| 2. Encrypt with AES-GCM-256 |
| K_migration = HKDF-SHA256(ECDH(...)) |
| |
| 3. Send Migration Stream |
|------------------------------------------>|
| |
| | 4. Decrypt &
| | Restore State
| | (AAI Context
| 5. Generate Forwarding Ticket | on New Host)
| (KEY = SHA-256(EID), New Locator) |
| |
| 6. Store in DHT & Invalidate Old Mapping |
| (after T_invalidate = 5 min) |
| |
v v
+------------------+ +-------------------+
| Old Host | | New Host |
| Invalidated | | Active |
+------------------+ +-------------------+
Gebauer Expires 29 January 2027 [Page 36]
Internet-Draft IACP - DHT July 2026
2.6.5. EID Revocation and Propagation
When an EID is compromised or when a curator key is revoked, the
affected node MUST execute a revocation procedure to invalidate the
compromised identity and propagate the revocation to the DHT overlay.
2.6.5.1. Revocation Trigger Conditions
An EID revocation is triggered under the following conditions:
1. Cryptographic Compromise: The private key associated with the EID
is known or suspected to be compromised. This is determined by
the node operator.
2. Curator Decapitation: A curator node is flagged by a validated
PoM ticket and undergoes quarantine.
3. Administrative Revocation: An explicit administrative directive
is issued by the managing user or parent orchestration system.
4. Reputation Threshold: The EID's reputation score falls below
R_state < 0.3 for T_reputation = 7 consecutive days.
2.6.5.2. Revocation Certificate
Upon triggering a revocation, the node generates a Revocation
Certificate. The certificate MUST include the following fields:
Revocation_Certificate = {
EID_Revoked: The EID being revoked (32 bytes),
EID_New: The new EID replacing the revoked one (32 bytes),
Timestamp: UNIX timestamp of revocation (8 bytes),
Reason: Revocation reason code (4 bytes),
Sequence_Number: Monotonically increasing sequence (8 bytes),
Signature: Sign_Ed25519(Private_Key_Old, EID_Revoked || EID_New ||
Timestamp || Reason || Sequence_Number)
}
Revocation Reason Codes:
| Code | Name | Description |
|------|----------------------|---------------------------------------|
| 0x01 | KEY_COMPROMISE | Private key exfiltrated or suspected |
| 0x02 | CURATOR_DECAPITATION | Curator node flagged by PoM |
| 0x03 | ADMINISTRATIVE | Administrative override |
| 0x04 | REPUTATION_FAILURE | Reputation score below threshold |
| 0x05 | OPERATIONAL_ROTATION | Scheduled rotation (Section 3.4) |
| 0x06 | KEY_LEAK_DETECTED | Key leak detected by external means |
Gebauer Expires 29 January 2027 [Page 37]
Internet-Draft IACP - DHT July 2026
The Signature MUST be verifiable against the EID_Revoked public key.
This proves that the revocation request originates from the
legitimate owner of the EID (or the holder of the private key at the
time of revocation).
2.6.5.3. Revocation Submission
The Revocation Certificate is submitted to the Global Directory
Quorum for the key SHA-256(EID_Revoked):
1. The node sends a REVOCATION_SUBMIT message to all 7 quorum nodes.
2. Each quorum node validates the certificate:
* Verify the Signature against EID_Revoked.
* Verify that Timestamp is within T_fresh = 5 minutes of current
time.
* Verify that Sequence_Number is greater than the last known
sequence for this EID.
* Verify that EID_New is a valid Ed25519 public key (not zero,
not already revoked).
* Verify that the EID_Revoked is not already in STATE_SLASHED.
3. If all checks pass, the quorum node responds with
REVOCATION_ACCEPT. Otherwise, REVOCATION_REJECT.
4. Consensus is reached when at least m = 4 out of 7 nodes have sent
REVOCATION_ACCEPT.
5. Upon consensus, each quorum node:
* Marks EID_Revoked as REVOKED in its local ledger.
* Records the mapping EID_Revoked -> EID_New for forwarding.
* Propagates the revocation to the DHT overlay.
2.6.5.4. Revocation Propagation
Once the revocation is committed by the quorum, it is propagated
through the DHT overlay:
1. Quorum nodes store the Revocation Certificate in the DHT under:
KEY = SHA-256("revocation:" || EID_Revoked)
Gebauer Expires 29 January 2027 [Page 38]
Internet-Draft IACP - DHT July 2026
2. The certificate is replicated with redundancy factor r = 7 and
has a TTL of T_revoke_ttl = 30 days. After T_revoke_ttl, the
revocation record expires and the EID MAY be reused (subject to
new key generation).
3. Nodes that encounter a stale revocation record (older than
T_revoke_ttl) MUST discard it and mark the EID as available for
reuse.
4. The EID_Revoked is added to a decentralized revocation bloom
filter for rapid lookup. The bloom filter is propagated to all
DHT nodes every T_bloom = 1 hour.
5. All active PSS sessions involving EID_Revoked: a. MUST be
terminated by both peers. b. SHOULD be re-established using
EID_New, subject to re-authentication.
2.6.5.5. Revocation Checking
Before accepting any PSS_INIT or processing any packet, a node MUST
check whether the target EID is revoked:
1. The node queries the local cache for the revocation status of the
target EID. The cache contains: a. Revoked EIDs (from quorum
commits) b. TTL for each entry (T_revoke_ttl = 30 days from
revocation)
2. If the target EID is in the cache: a. The node MUST reject the
PSS_INIT. b. The node MUST respond with PSS_REJECT (Reason:
EID_REVOKED). c. The node SHOULD suggest EID_New if available.
3. If the target EID is not in the cache, the node performs a DHT
lookup under KEY = SHA-256("revocation:" || EID_Revoked).
4. If a revocation record exists: a. The node MUST add the EID to
its local cache. b. The node MUST reject the PSS_INIT. c. The
node SHOULD cache EID_New for future forwarding.
5. If no revocation record exists, the node assumes the EID is
valid.
2.6.5.6. Revocation Forwarding
To ensure continued communication during EID rotation, the revoked
EID MAY forward packets to the new EID:
1. The DHT stores a forwarding mapping for T_forward = 7 days: KEY =
SHA-256("forward:" || EID_Revoked) -> EID_New
Gebauer Expires 29 January 2027 [Page 39]
Internet-Draft IACP - DHT July 2026
2. Nodes receiving a packet destined for EID_Revoked during
T_forward:
* Check the forwarding mapping.
* If found, forward the packet to EID_New.
* Include a FORWARDED header to indicate the redirection.
3. After T_forward, the forwarding mapping expires and packets to
EID_Revoked are dropped.
2.6.5.7. Revocation Recovery (Accidental Revocation)
If a revocation was issued in error, the node MAY submit a Revocation
Reversal Certificate:
Revocation_Reversal = {
EID_Revoked: The EID that was revoked (32 bytes),
EID_New: The EID that was intended to replace it (32 bytes),
Timestamp: UNIX timestamp of reversal (8 bytes),
Reason: Reversal reason code (4 bytes),
Signature: Sign_Ed25519(Private_Key_New, EID_Revoked || EID_New ||
Timestamp || Reason)
}
The Reversal MUST be submitted to the quorum within T_reversal = 1
hour of the original revocation. If accepted by consensus, the
quorum reverses the revocation and removes EID_Revoked from the
revocation bloom filter.
2.7. Layer-Separated Economic Governance and Edge Gatekeeper Model
The IACP employs a strict separation between transport-layer
forwarding and application-layer/authorization logic.
2.7.1. Layer 4 Kernel-Space Fast-Path
The IACP architecture defines a logical L4 fast-path responsible for
low-latency, high-throughput processing of incoming packets before
they are handed to the application layer. This fast-path operates at
the kernel or dataplane layer and is decoupled from the L7
application-space logic. Its responsibilities are:
* Basic header validation and rate limiting.
* Sequence vector and replay protection checks.
Gebauer Expires 29 January 2027 [Page 40]
Internet-Draft IACP - DHT July 2026
* Forwarding of opaque authorization envelopes to the L7 gateway.
* Immediate session teardown upon receiving a signal from the L7
layer.
The L4 fast-path MUST remain agnostic to the semantics of
authorization tokens; it performs only structural validation (e.g.,
verifying header format, checking sequence numbers) and forwards the
opaque payload without interpretation.
The specification uses eBPF as the reference implementation mechanism
for the L4 fast-path, but this is not a requirement. The L4 fast-
path is defined as an abstract functional component, not as a
specific implementation technology. Conforming IACP implementations
MAY implement the L4 fast-path using other mechanisms, including:
* XDP (eXpress Data Path) for high-performance packet processing
(similar to eBPF).
* DPDK (Data Plane Development Kit) for userspace packet processing.
* A pure userspace implementation using standard sockets (for
resource-constrained or development environments).
* Hardware offloading on network interface cards (if supported).
* Platform-specific kernel modules (e.g., Windows Filtering
Platform, Apple Network Extension).
Regardless of the implementation mechanism, the L4 fast-path MUST
provide the following functional guarantees:
* The fast-path MUST be capable of processing packets at line rate
(or as close to it as the underlying hardware permits).
* The fast-path MUST NOT allocate significant memory or state for
packets that fail basic validation.
* The fast-path MUST forward opaque authorization envelopes to the
L7 gateway without modification.
* The fast-path MUST accept and act on teardown signals from the L7
gateway.
Implementations using eBPF or XDP SHOULD follow the best practices
for packet processing defined in the Linux kernel documentation.
Implementations using other mechanisms SHOULD provide equivalent
performance and security properties.
Gebauer Expires 29 January 2027 [Page 41]
Internet-Draft IACP - DHT July 2026
2.7.2. Layer 7 Application-Space Door-Keeper (Opaque Authorization
Envelope)
EMILIA Receipt Handling and Verification
The Opaque Authorization Envelope (Section 5.7.2) carries EMILIA
receipts as opaque byte arrays. The IACP protocol itself does not
interpret, canonicalize, or verify the contents of the envelope.
An IACP implementation that wishes to verify a carried EMILIA receipt
SHOULD call the EMILIA reference verifier on the envelope bytes and
the sender's pinned public key. The verifier performs the JCS
canonicalization [RFC8785] and signature verification internally.
The canonicalization profile is defined in
[I-D.schrock-ep-authorization-receipts], where the action hash is the
SHA-256 of the JCS-canonical action.
The EMILIA reference verifier is available in the following
implementations:
* npm: @emilia-protocol/verify
* PyPI: emilia-verify
* Go: github.com/emiliaprotocol/emilia-protocol/packages/go-verify
Implementations that choose to perform canonicalization on the IACP
side MUST use the conformance vectors provided in the EMILIA
repository (canonicalization.v1.json) to ensure byte-for-byte
compatibility, as any canonicalization difference between two
implementations constitutes a signature-forgery surface.
2.7.3. Asynchronous Verification and Teardown
Full validation of authorization logic (EMILIA signature
verification, WRT budget check, etc.) occurs asynchronously in
application space. However, the L7 fast-path pre-validation does not
constitute a durable authorization grant, it is solely a structural
check of the opaque authorization envelope's format, nonce, and
signature shape, with the actual authorization decision deferred to
the asynchronous application-space verification.
If a violation is detected: - The L7 gateway SHALL immediately issue
a targeted teardown signal to the L4 layer. - The L4 layer MUST
terminate the affected PSS and associated ESEs. - The offending EID
SHALL be placed on a temporary deny-list (ranging 5–60 minutes,
configurable per namespace). - Permanent EID revocation MUST only
occur after a validated Proof of Malfeasance (PoM) by DHT curators.
Gebauer Expires 29 January 2027 [Page 42]
Internet-Draft IACP - DHT July 2026
For security reasons, authorization failures SHOULD use silent
teardown (no specific error code exposed to the sender).
The diagram below serves as illustration of this part:
+-------------------------------------------------------+
| L4 Fast-Path (eBPF) |
| - Header & Rate Limit Validation |
| - Sequence Vector Replay Checks |
+-------------------------------------------------------+
|
v [Forwarding Opaque Envelope]
+-------------------------------------------------------+
| L7 Application Gateway |
| - Opaque Authorization Envelope Processing |
| - Fast-Path Pre-Validation (Signature, Nonce, Format) |
+-------------------------------------------------------+
| |
v (Pass: Allocation Granted) v (Fail)
+-----------------------+ +-----------------------+
| DHI Execution Context | | Silent Session Drop |
| & Active PSS / ESEs | | & Threat Signal |
+-----------------------+ +-----------------------+
| |
v (Asynchronous Full Validation) |
+-----------------------+ |
| App-Space Verification| |
| (EMILIA / WRT Check) | |
+-----------------------+ |
| |
v (If Violation Detected) v
+-------------------------------------------------------+
| Targeted L4 Teardown Vector Signal |
| - Terminate Affected PSS & Associated ESEs |
| - Temporary EID Deny-List Placement (5-60 min) |
+-------------------------------------------------------+
3. References
3.1. 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/info/rfc2119>.
Gebauer Expires 29 January 2027 [Page 43]
Internet-Draft IACP - DHT July 2026
[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/info/rfc8174>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
3.2. Informative References
[Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
Information System Based on the XOR Metric", IPTPS 2002,
2002.
[Hashcash] Back, A., "Hashcash - A Denial of Service Counter-
Measure", Whitepaper 2002, 2002.
[I-D.schrock-ep-authorization-receipts]
Schrock, I., "EMILIA Protocol Specification", Work in
Progress, Internet-Draft, draft-schrock-ep-authorization-
receipts, 2026, <https://datatracker.ietf.org/doc/draft-
schrock-ep-authorization-receipts/>.
Author's Address
Gebauer Expires 29 January 2027 [Page 44]
Internet-Draft IACP - DHT July 2026
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 29 January 2027 [Page 45]