MUX Status Frame: Two-Way Reachability Signalling without an Enumeration Oracle

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. 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.

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.

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.

Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Caller:: the party whose traffic reaches the mux.
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 ().
Tombstone:: a canonical, self-verifiable record that an identity has been permanently revoked.

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.

Octet 0 - Status

Octet 1 - Hint

Encoding The two octets are the contract. Implementations MUST sign, verify, and compare over exactly these octets.

The Anti-Enumeration Invariant If disclosure is 00 (the world), or the caller has no relationship with the target (), 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.

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.

Status Resolution The status fields are derived from the canonical naming record (AINS) and session liveness, in this order:

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.

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.

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 , 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.

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.

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 () 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.

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.

Worked Vectors 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 ]]> 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.