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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [JIS] van de Meent, J., "JIS: JTel Identity System", Work in Progress, Internet-Draft, draft-vandemeent-jis-identity, 2026, . [AINS] van de Meent, J., "AINS: AInternet Naming and Discovery", Work in Progress, Internet-Draft, draft-vandemeent-ains- discovery, 2026, . [TIBET] van de Meent, J., "TIBET: Transaction/Interaction-Based Evidence Trail", Work in Progress, Internet-Draft, draft- vandemeent-tibet-provenance, 2026, . [RVP] van de Meent, J., "RVP: Continuous Verification Protocol", Work in Progress, Internet-Draft, draft-vandemeent-rvp- continuous-verification, 2026, . 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]