MUX Status Frame: Two-Way Reachability Signalling without an Enumeration Oracle
draft-vandemeent-mux-status-frame-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) | |
|---|---|---|---|
| Authors | Jasper van de Meent , Root AI | ||
| Last updated | 2026-06-17 | ||
| 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-vandemeent-mux-status-frame-00
Internet Engineering Task Force J. van de Meent
Internet-Draft R. AI
Intended status: Informational Humotica
Expires: 19 December 2026 17 June 2026
MUX Status Frame: Two-Way Reachability Signalling without an Enumeration
Oracle
draft-vandemeent-mux-status-frame-00
Abstract
This document defines the MUX Status Frame, a two-octet,
relationship-scoped signal that lets a multiplexing routing layer
tell a proven, related peer that a destination is unavailable -
offline, not in session, superseded, or permanently revoked
(tombstoned) - while disclosing nothing to the open network. It
resolves the tension between two failure modes of a null-routing mux:
silently dropping traffic to a dead peer (a false positive - the
sender believes it landed) and answering honestly to everyone (an
enumeration oracle mapping who is alive, dead, or revoked). Honest
status travels only on a relationship-scoped trusted path; to the
world, and to any merely authenticated but unrelated peer, the entire
frame is zero. Status is derived from the canonical naming record
and session liveness, not from a separate blocklist. The encoding is
deterministic so independent implementations agree byte-for-byte.
This protocol is transport-agnostic and complements JIS [JIS], AINS
[AINS], TIBET [TIBET], and RVP [RVP].
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 19 December 2026.
van de Meent & AI Expires 19 December 2026 [Page 1]
Internet-Draft MUX Status Frame June 2026
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Status Frame . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Octet 0 - Status . . . . . . . . . . . . . . . . . . . . 4
3.2. Octet 1 - Hint . . . . . . . . . . . . . . . . . . . . . 4
3.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Anti-Enumeration Invariant . . . . . . . . . . . . . . . 5
5. Relationship Scoping . . . . . . . . . . . . . . . . . . . . 5
6. Status Resolution . . . . . . . . . . . . . . . . . . . . . . 5
7. Sender Behaviour . . . . . . . . . . . . . . . . . . . . . . 6
8. Layer Boundary . . . . . . . . . . . . . . . . . . . . . . . 6
9. Fail-Safe and Determinism . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Worked Vectors . . . . . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A multiplexing routing layer ("mux") that protects a host commonly
absorbs abnormal traffic into silence (a null route). Silence is the
correct posture toward an unknown scanner. It is the wrong posture
toward a legitimate sender whose destination is genuinely gone: the
sender (a human or an autonomous agent) believes its message landed
when in fact it fell into a black hole.
van de Meent & AI Expires 19 December 2026 [Page 2]
Internet-Draft MUX Status Frame June 2026
The naive fix - reply "dead" - is worse. Any response that varies
with the state of a name turns the mux into an enumeration oracle: an
attacker can map which identities exist, which are alive, and which
have been revoked. The honest signal and the leak are the same
signal.
This document resolves the tension by scoping honesty to a prior
relationship. The mux emits a real status only to a peer that is
both cryptographically proven and already had a binding with the
destination; to everyone else the frame is indistinguishable from the
silent default. The distinction is the entire mechanism.
1.1. Problem Statement
Two failure modes must be eliminated simultaneously:
* False-positive delivery: a sender to a dead or revoked peer must
not believe it succeeded.
* Enumeration oracle: the network at large must not learn the
liveness or revocation state of any name from a differential
response.
1.2. Design Principles
* Relationship-scoped, not auth-scoped. Authentication alone does
not earn a status; a prior binding does.
* No separate blocklist. Status is read off the canonical naming
record that the resolver already verifies.
* Silence is the floor. Unknown caller, no relationship, or any
computation error yields a zero frame.
* Deterministic. The two octets are a pure function of inputs, so a
second implementation matches byte-for-byte.
* Reachability only. The mux reports whether a destination can be
reached, never whether a recipient consented or acted.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals.
Caller: the party whose traffic reaches the mux.
van de Meent & AI Expires 19 December 2026 [Page 3]
Internet-Draft MUX Status Frame June 2026
Target: the named destination the caller is trying to reach,
expressed as a JIS actor or AINS name.
Proven peer: a caller whose identity is cryptographically verified
(e.g. a JIS Ed25519 challenge-response).
Relationship: a prior bilateral binding between caller and target
(Section 5).
Tombstone: a canonical, self-verifiable record that an identity has
been permanently revoked.
3. The Status Frame
The frame is two octets carried in a reserved field of the mux
envelope. Octet 0 is the status; octet 1 is a hint.
3.1. Octet 0 - Status
bits 7-6 disclosure
00 silent / no disclosure (the world) 01 trusted
10 policy / security 11 reserved
bits 5-4 state class
00 accepted / alive 01 transient / degraded
10 unavailable / dead 11 policy / quarantine
bits 3-0 reason
0000 none 0001 heartbeat-dead 0010 not-in-session
0011 not-registered 0100 consent-missing 0101 tombstone-confirmed
0110 successor-available 0111 assurance-expired
1000-1111 reserved
3.2. Octet 1 - Hint
bits 7-6 retry
00 no-hint 01 retry-soon 10 retry-later 11 do-not-retry-auto
bits 5-4 detail source
00 none 01 local-mux 10 local-cache/last-known
11 signed-external / canonical-ref
bits 3-0 detail code
0000 none 0001 route-missing 0010 endpoint-inactive
0011 runtime-wrapper-missing 0100 session-expired
0101 local-tombstone 0110 canonical-tombstone
0111 successor/ref-available 1000-1111 reserved
3.3. Encoding
octet0 = (disclosure << 6) | (state_class << 4) | reason
octet1 = (retry << 6) | (detail_source << 4) | detail_code
van de Meent & AI Expires 19 December 2026 [Page 4]
Internet-Draft MUX Status Frame June 2026
The two octets are the contract. Implementations MUST sign, verify,
and compare over exactly these octets.
4. The Anti-Enumeration Invariant
If disclosure is 00 (the world), or the caller has no relationship
with the target (Section 5), the entire frame MUST be 0x0000. An
implementation MUST NOT leak state class or reason through the lower
bits when disclosure is 00; doing so reconstitutes the enumeration
oracle through the nibbles. Honest status travels only at disclosure
01 (trusted) or 10 (policy/security).
Alive is implicit by routing. A reachable endpoint simply forwards
traffic; an implementation MUST NOT broadcast an unsolicited "alive"
frame, which is itself enumerable. An explicit alive acknowledgement
(0x40nn) is OPTIONAL and is only a response to an explicit status
query on the trusted path.
5. Relationship Scoping
The security of the frame depends on the relationship predicate, so
independent implementations MUST decide it identically. A
relationship exists when the target can verify a prior bilateral
binding with the caller. At least one of the following MUST hold:
* an active session between caller and target;
* a local mux-lane registration linking the two;
* a prior AINS/JIS binding recorded between them;
* recorded bilateral consent;
* an existing tombstone-relation (the caller previously held a
binding now revoked).
Authentication alone - a valid signature from an otherwise unknown
peer - is NOT a relationship. Treating it as one would make every
trusted peer an enumeration oracle for every name. When the
predicate cannot be established, the implementation MUST treat it as
absent and emit 0x0000.
6. Status Resolution
The status fields are derived from the canonical naming record (AINS)
and session liveness, in this order:
van de Meent & AI Expires 19 December 2026 [Page 5]
Internet-Draft MUX Status Frame June 2026
* record marks revocation/tombstone: dead, tombstone-confirmed, do-
not-retry, signed-canonical, canonical-tombstone (0x65 0xF6);
* record has a successor/alias: dead, successor-available, do-not-
retry, signed-canonical, successor/ref (0x66 0xF7);
* record reserved/pending or absent: transient, not-registered;
* positive evidence the lane is quiet: transient, not-in-session;
* otherwise: alive (implicit; silent on the wire).
An implementation MUST NOT assert not-in-session without positive
evidence that the lane is quiet; absent such evidence a registered
name resolves as alive.
7. Sender Behaviour
A receiving sender keys on the state class: alive means proceed;
transient means retry per the retry bits; dead means stop or follow
the hint; quarantine means stop. On successor-available the sender
SHOULD re-resolve the target to its successor and retry there. The
detail-source field is a confidence gradient on the evidence (local-
mux < local-cache < signed-canonical-ref); a sender MAY weight
automated action by it. A canonical tombstone with detail-source
signed-canonical-ref is self-verifiable offline.
8. Layer Boundary
The frame is a reachability/liveness posture, not a delivery or read
receipt. A live actor that refuses an action is a consent decision
(for example an authorization failure), and MUST NOT be encoded as a
mux status. Whether a recipient read or acted on a message is a
separate, higher-layer signed receipt [TIBET], never these octets.
Informatively, the frame maps onto familiar messaging semantics: a
single check (queued, lane not live) corresponds to transient; a
double check (delivered to a live lane) to alive; "blocked" to dead
or quarantine. A read/acted indication is not derivable from the mux
and belongs to the receipt layer.
van de Meent & AI Expires 19 December 2026 [Page 6]
Internet-Draft MUX Status Frame June 2026
9. Fail-Safe and Determinism
Silence is the absolute floor. If status cannot be computed - the
naming record is unreachable, a lookup times out, or any error occurs
- the implementation MUST emit 0x0000 and MUST NOT fail open to a
permissive state. Status resolution SHOULD be performed against a
local replica of the canonical record to avoid network-dependent
stalls; where a remote lookup is unavoidable it MUST be bounded by a
timeout whose expiry yields 0x0000. The encoding is deterministic:
identical inputs yield identical octets.
10. Security Considerations
The central property is non-enumerability: the frame MUST reveal
nothing to a caller that is not a proven, related peer. The
relationship predicate (Section 5) is the load-bearing control;
weakening it to authentication alone reintroduces the oracle.
Context extraction at the mux MUST be bounded and MUST NOT parse
unbounded request bodies, so the resolution step cannot itself become
a denial-of-service surface; a length-capped, shape-checked target
identifier from a header or path is the intended input. A bad or
missing identity proof MUST NOT earn status. Because status derives
from the canonical record, revocation propagates without a
distributable blocklist; an attacker cannot enumerate the blocklist
because there is none.
11. IANA Considerations
This document requests, on adoption, three registries with reserved
ranges for future allocation: "MUX Status Reason Codes" (octet 0,
bits 3-0), "MUX Hint Retry/Source" (octet 1, bits 7-4), and "MUX
Detail Codes" (octet 1, bits 3-0). Code points 1000-1111 in each
nibble are Reserved. The allocation policy is Specification
Required.
12. Worked Vectors
caller = world / unproven, ANY target -> 0x0000
caller = trusted, NO relationship, ANY target -> 0x0000
trusted + relationship, alive (explicit ack) -> 0x4000
trusted + relationship, heartbeat-dead -> 0x5152
trusted + relationship, not-in-session -> 0x5293
trusted + relationship, not-registered -> 0x5351
trusted + relationship, canonical tombstone -> 0x65F6
trusted + relationship, successor available -> 0x66F7
van de Meent & AI Expires 19 December 2026 [Page 7]
Internet-Draft MUX Status Frame June 2026
The two negatives - world and trusted-without-relationship over a
tombstoned target both yielding 0x0000 - are the conformance
guarantee: an implementation that "honestly" returns the dead nibble
to the world fails them. A runnable interoperability vector set and
reference verifier exist as "mux_status_v10" in the TIBET
communications conformance kit; implementations SHOULD verify against
the published vectors, including the anti-enumeration negatives,
rather than against any single reference implementation.
13. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[JIS] van de Meent, J., "JIS: JTel Identity System", Work in
Progress, Internet-Draft, draft-vandemeent-jis-identity,
2026, <https://datatracker.ietf.org/doc/html/draft-
vandemeent-jis-identity>.
[AINS] van de Meent, J., "AINS: AInternet Naming and Discovery",
Work in Progress, Internet-Draft, draft-vandemeent-ains-
discovery, 2026, <https://datatracker.ietf.org/doc/html/
draft-vandemeent-ains-discovery>.
[TIBET] van de Meent, J., "TIBET: Transaction/Interaction-Based
Evidence Trail", Work in Progress, Internet-Draft, draft-
vandemeent-tibet-provenance, 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
tibet-provenance>.
[RVP] van de Meent, J., "RVP: Continuous Verification Protocol",
Work in Progress, Internet-Draft, draft-vandemeent-rvp-
continuous-verification, 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
rvp-continuous-verification>.
Authors' Addresses
Jasper van de Meent
Humotica
Netherlands
Email: jasper@humotica.nl
URI: https://humotica.nl
van de Meent & AI Expires 19 December 2026 [Page 8]
Internet-Draft MUX Status Frame June 2026
Root AI
Humotica
Email: root_idd@humotica.nl
URI: https://humotica.nl
van de Meent & AI Expires 19 December 2026 [Page 9]