Validating Inline Enforcement with XDP: IBSR and the Path to Earned Autonomy

NullRabbit is building an inline defence system for internet-facing infrastructure. The goal is enforcement at the earliest point in the packet path, with the predictability required for production.

IBSR (Inline Block Simulation Report) is the first step.

It is not enforcement. It is validation: run real traffic through the same execution path that enforcement would use, measure the impact, and generate an auditable report - before any traffic is blocked.

Why the packet ingress layer matters

Validators, RPC nodes, APIs, and control planes are deployed across heterogeneous environments, often directly reachable from the public internet. The earliest packet-handling layer is where security decisions have the most leverage - and where mistakes are most costly.

Blocking traffic too late wastes resources. Blocking too early takes the system offline.

XDP as a foundation

XDP (eXpress Data Path) runs at the earliest possible point in the Linux networking stack - directly in the NIC receive path.

Packets processed by XDP have not yet passed through:

• iptables / nftables
• TCP or UDP socket dispatch
• user-space applications

This makes XDP suitable for early measurement, coarse filtering, and deterministic enforcement. This is the same architecture Cloudflare uses for L4 DDoS mitigation - XDP programs doing bounded, per-packet work with no userspace involvement in the fast path.

The packet path

IBSR runs inside the XDP program.

The program executes once per packet. The BPF verifier enforces bounded loops, no dynamic allocation, and no blocking. The only side effect is map writes - O(1) hash operations into memory that userspace reads asynchronously. No syscalls on the packet path.

Observe first, enforce later

Inside the XDP program, responsibilities are architecturally split:

• IBSR Observe (default, implemented)
• Guard Enforce (opt-in, future)

IBSR operates in observe-only mode. It measures and simulates - it does not block.

How IBSR works

For each packet, IBSR:

• extracts traffic features: source IP, destination port, TCP flags
• increments counters in a bounded eBPF map (LRU hash, 100K entries)
• returns XDP_PASS

There is no packet capture, no payload inspection, no replay, no conditional enforcement logic.

All operations are constant-time and verifier-safe. Traffic continues through the Linux networking stack exactly as it would without IBSR present.

Latency and performance

IBSR follows the same constraints as production XDP programs used for load balancing and metrics:

• no syscalls on the packet path
• no userspace coordination per packet
• no dynamic allocation
• bounded map sizes

Packet processing cost is predictable. Latency impact is negligible.

If the XDP program is unloaded or fails verification, the kernel falls back to the normal networking path. Traffic continues uninterrupted.

Offline reporting

IBSR separates collection from analysis.

Counters are collected in kernel space. A userspace daemon (ibsr-daemon) reads them periodically. Analysis and report generation happen offline.

An IBSR report shows:

• what would have been blocked
• under which rules
• with what impact

There is no inbound control plane. There is no automatic policy push. There is no path from measurement to enforcement without explicit human intervention.

What IBSR is not

• IBSR does not enforce policy. IBSR does not make decisions. IBSR does not "solve" security.
• IBSR answers one question: if we enforced a rule, what would actually happen?

Only once that answer is understood does enforcement become reasonable.

Enforcement

Enforcement (Guard) is a separate component, built on the same XDP foundation. Guard is opt-in, deterministic, and intentionally simple. It executes pre-approved rules - it does not learn.

Guard is future work. IBSR is how we validate that it should exist.

Open source

IBSR is open source. Operators can inspect exactly what runs at packet ingress and reproduce the reporting workflow.

Repository: https://github.com/NullRabbitLabs/nr-ibsr/

Summary

IBSR uses XDP to validate inline enforcement before it exists. It observes real traffic at the earliest packet ingress point, measures impact without blocking, and generates reports offline.

NullRabbit is building the enforcement system. IBSR is how we prove it should exist.

Get in touch with the team to discuss helping us build the future of defence.