RRFC Gate

Full project description

Inspiration

Some high-assurance servers should be almost unreachable. A signing or build host, control-plane machine, agent server, or other sensitive system may need one controlled path for administration or automation, but a general inbound or outbound network surface grants far more authority than the job requires. RRFC Gate began with that operational problem.

Traditional firewalls are good at addresses and protocols, but an opaque application protocol creates a second question: how can a firewall prove that encrypted-looking traffic is genuinely from the intended system? Packet shape is not authentication, and an imitator can reproduce framing.

RRFC Gate grew out of a larger body of theory and experiments. Librarian investigates relational epistemic systems; RRFC carries that research into a communications architecture; PHIc explores its use for messaging; and RRSH explores remote access. The gate tackles the complementary endpoint question: how can an operating system give that communication one narrowly scoped path while denying every other network path? The private RRFC construction and its security claims remain outside this submission; the public enforcement layer can be understood and tested independently.

RRFC Gate starts from a different premise: do not ask the packet to prove what it is. Control which process has network authority, restrict that process to exact carrier coordinates, and expose typed local capabilities instead of a generic byte tunnel.

What it does

RRFC Gate is a fail-closed endpoint firewall prototype for high-assurance servers that admit only narrowly scoped RRSH communication.

• Linux nftables blocks direct networking for ordinary workloads and root.
• One dedicated non-root broker identity can reach only an exact carrier allow-list.
• Local clients can request a typed RRSH session but cannot choose a destination, port, executable, grant, remote command, or arbitrary payload.
• A separately delivered capability core is represented through the smallest opaque trust-and-permit seam. Its patent-bearing behavior is not published here.
• Signed-entry lab mode verifies ownership, permissions, path ancestry, platform, digest, detached signature, public version, and grant access before creating its local socket.
• Any missing trust, malformed request, wrong permit, artifact mismatch, peer outage, or policy failure returns a coarse denial and keeps the gate closed.

Why this is more than "allow one program"

An executable allow-list alone would not prove which operation was requested, and a packet signature would be easy to imitate. RRFC Gate therefore combines two independent boundaries. The kernel confines external networking to one broker identity and exact approved carriers. The broker accepts only typed capabilities and invokes a fixed RRSH operation after opaque permit admission; it never offers callers arbitrary bytes, destinations, commands, or port forwarding.

RRSH still rides conventional network transport, but it does not treat that transport as a self-contained plaintext or ciphertext command stream. It carries relational RRFC data whose usable context exists at the participating endpoints. Under the current RRFC model and evidence, a party that has not compromised either endpoint has no known way to construct a meaningful attacker-chosen RRSH command: carrier interference can corrupt, sever, or flood the relation, producing denial rather than chosen injection.

That is a structural research claim, not an independently reviewed cryptographic guarantee. Endpoint compromise remains decisive, and timing, addresses, traffic volume, and denial of service remain visible risks. RRFC Gate does not claim to prove RRFC's private security construction; it makes the complementary endpoint-enforcement layer small, fail-closed, and independently testable.

How we built it

The project is written in Rust with no third-party crate dependencies. The Linux backend renders atomic nftables transactions and installs before normal networking through systemd. A bounded Unix-domain broker exposes a deliberately tiny local protocol. Platform-neutral tests cover policy and parsing, while an isolated Debian VM provided boot, identity, carrier-counter, outage, and recovery evidence through a Proxmox out-of-band console.

The real RRSH executable remained a separately distributed signed artifact. Private grants and patented RRFC internals never entered the repository, logs, test vectors, or demo. Judges can run a deterministic eight-check binary that exercises the published control-flow boundary without network access or rebuilding.

How Codex accelerated the work

Codex was the primary implementation and verification collaborator. It helped turn the initial product idea into an endpoint/capability architecture, implement the Rust and Linux layers, generate adversarial tests, operate the disposable test environment, and maintain an append-only development ledger.

Codex also found a real availability issue during red teaming: one partial local request could delay another client. It then implemented a fixed worker pool and bounded queue, extended the saturation tests, and verified that the fix did not widen network authority.

The human operator retained the key decisions: protecting the RRFC patent boundary, rejecting packet-shape authentication, denying raw forwarding, requiring independent kernel and semantic admission, approving privileged test scope, and keeping the submission repository private.

Before submitting, replace the next line only after checking the product UI:

Model confirmation: GPT 5.6 Sol High

Challenges

The hardest part was proving useful behavior without publishing the system that creates the private permits. That forced a clean separation between public enforcement logic, scripted test doubles, signed external artifacts, and private integration material.

The second challenge was safely testing a firewall whose success condition removes SSH and root networking. The answer was a disposable QEMU guest, boot-persistent default deny, atomic policy replacement, and QEMU guest-agent recovery outside the filtered network path.

Accomplishments

• 28 functional and adversarial Rust tests pass on Windows and Linux.
• The judge demo performs 8 deterministic fail-closed checks without private material.
• The live red-team runner passed 19 bounded attack phases after one finding was fixed.
• Eight signed-artifact substitution cases failed before socket creation.
• A valid typed request advanced exactly one RRSH carrier rule.
• Wrong permits and unsupported operations produced no carrier traffic.
• Ordinary-user and root direct carrier attempts remained blocked.
• Peer outage returned only UNAVAILABLE, and recovery restored service without restarting the broker.

What we learned

Opaque protocols should be gated by authority and capability, not guessed from bytes. Fail-closed behavior also has to survive startup, reboot, overload, artifact failure, and recovery—not only the happy path. Finally, a strict intellectual-property boundary can improve architecture by forcing the public interface to remain small and testable.

What's next

The next engineering step is a reviewed private adapter for the production capability core, followed by peer-credential authorization, per-identity rate limits, file-replacement race tests, signer rotation, rollback/drift handling, and a persistent reviewed broker service. The current submission is an experimentally validated prototype, not a production security claim.

Built With

• codex
• gpt-5.6-sol
• linux-nftables
• proxmox
• rrfc
• rrsh
• rust
• systemd
• unix-domain-sockets