Garlic in a Box: I2P Network Emulator

Garlic in a Box: I2P Network Emulator Siddique Abubakr Muntaka∗ , Faiza Hussein† , Boutros Farah‡ , Anthony Kashi‡ , Jacques Bou Abdo∗ , Jacques Demerjian‡§ ∗ School of IT, University of Cincinnati, OH, USA † Dept. of Computer Science, Garden City University College, Ghana ‡ LaRRIS, Faculty of Sciences, Lebanese University, Lebanon

§ Faculty of Arts and Sciences, USEK, Lebanon

arXiv:2610.34004v1 [cs.NI] 25 Oct 2026

{muntaksr@mail.uc.edu, bouabdjs@ucmail.uc.edu} Abstract—The Invisible Internet Project (I2P) is a peer-to-peer anonymity network whose routing and peer-selection mechanics underlie a growing family of state-sponsored covert relay architectures. Studying these mechanics demands a controlled, reproducible environment. We present G ARLIC - IN - A -B OX, an installable emulator that deploys a fully isolated network of unmodified I2P Java routers on a single host or cluster of hosts. Each router runs in its own Linux network namespace. A filesystem bootstrap removes the dependency on signed reseed servers, and synthetic geographic diversity activates the same location-aware peer-selection code paths present on the live network. A fifty-router deployment across five geographic locations stabilises in about twenty-five minutes and uses roughly 21 GB of memory. To demonstrate the platform’s value, we model I2P peer selection as a two-stage process and conduct a reputation attack. Across five independent trials, the attack promotes the adversary into the victim’s eligible selection set with perfect consistency, and the adversary is chosen for 1.38× more tunnels than matched controls. The platform and its measurement pipeline are released to support reproducible I2P security research and hands-on cyber-defence training. Index Terms—I2P, anonymous overlay, network emulator, peer selection, reputation attack, cybersecurity training, national security.

these covert ecosystems as a strategic national security threat [6]. Whether the goal is to disrupt such traffic or to train the operators who must respond to it, the first requirement is the same: a clear understanding of how these networks decide where traffic goes. That understanding is difficult to obtain. The live I2P network cannot be experimented on without raising ethical and reproducibility concerns, and a handful of manually assembled routers cannot capture the network-level behavior that a realistic deployment produces. Neither option gives an educator a safe place to teach these attacks in the first place. We present G ARLIC - IN - A -B OX, an installable emulator that closes this gap. It runs unmodified I2P Java routers, each isolated in a Linux network namespace, and provides a control interface, a scenario engine, and a measurement pipeline. The platform answers two needs at once. It gives researchers a controlled instrument for observing router behavior and collecting protocol data at scale, from peer selection and tunnel construction to any interaction the unmodified router exposes. It also gives defenders a safe range on which to rehearse against the protocol mechanics that covert relay networks now exploit. In support of these goals, this paper contributes the following.

1. Introduction The Invisible Internet Project (I2P) is a peer-to-peer anonymity network in which no router is merely a client [1]. Each one relays for others, and each one chooses the peers that make up its own tunnels from a reputation database it maintains locally. Those choices decide who can observe a flow, who can correlate it, and how much anonymity the network ultimately provides. They are also the point where the network is most open to manipulation, since an adversary able to influence those choices can raise its own standing in a victim’s selection process. This has become more than a theoretical concern. Operational Relay Box (ORB) networks operated by actors such as APT28, Volt Typhoon, and SPACEHOP have begun to reuse the peer-selection and relay-management techniques of anonymity systems, I2P prominent among them, spreading across compromised infrastructure on a scale no volunteer network approaches [2]–[5]. A Cybersecurity and Infrastructure Security Agency (CISA) advisory in April 2026 flagged

1) 2)

3) 4)

5)

A packaged, reproducible I2P emulator (Section 3) that runs unmodified routers in isolated namespaces and bootstraps without a signed reseed server. A two-stage probabilistic model of I2P peer selection (Section 5.1), distinguishing the selection stage, where a peer becomes eligible, from the delivery stage, where it must actually relay traffic. A profiles-as-measurement method (Section 5.2) that reads the victim’s own on-disk peer state to quantify attack effects on an unmodified router. A five-trial empirical study (Section 5.3) of a reputation attack, with a deterministic result on the selection stage and a precise account of the delivery stage. A structured training capability (Section 6) that supports red-team and blue-team exercises on anonymous overlay threats, including scenarios relevant to ORB-style covert relay operations.

2. Background and Related Work I2P is a message-oriented anonymous overlay [7]. Routers publish RouterInfo records to a distributed hash table called the netDb, which is replicated by a subset of nodes designated as floodfill peers [8]. Traffic travels through paired unidirectional tunnels, rebuilt approximately every ten minutes [9]. A router selects the peers in its own tunnels from a local reputation database [10]. The security properties of the network follow directly from those selection decisions. Each I2P router keeps a profile for every peer it has interacted with, accumulating observed bandwidth, tunnel-build acceptance and rejection rates, and response latency [11]. The ProfileOrganizer sorts these profiles into tiers on a coalescing timer, admitting the best-observed peers into a fast tier and a high-capacity tier from which tunnel hops are drawn [12]. Alongside these measured quantities, every profile keeps two explicit bonus fields, speedBonus and capacityBonus. Their effect is to nudge a peer’s standing without reference to anything it has actually done, which is precisely what makes them attractive to an attacker: manipulating profile state amounts to writing directly to these fields rather than earning a reputation through behaviour. Whether such a nudge is enough to matter was settled by Herrmann and Grothoff, whose real-world study of I2P found that performance-based selection already introduces measurable bias even when peers behave benignly [13]. If honest variation in observed performance is enough to skew selection, then a small change to a peer’s stored state can just as easily push it from one tier into another. Fig. 1 follows this process from start to finish: a new router first gathers peers through reseed, maintains and updates their profiles in a local database, and then, when assembling tunnels, draws its hops preferentially from the fast and high-capacity groups that the ProfileOrganizer curates [14]. New Router (nR)

HTTPS Request (URL) : https://reseed.i2p-projekt.de/reseed.zip

Peers

Reseeding Server (I2P Router)

Client Tunnel Exploratory Tunnel

Visible Web Random Pick

Exploratory Tunnel Peers

FF1

Prior I2P studies have examined netDb crawling [15], practical attacks including Sybil and intersection variants [16], peer-profile bias [12], [13], resilience properties [17], and the construction of validated data-collection frameworks [18]. Each of these required bespoke testbed setups that are not reusable. Jansen and Hopper’s Shadow [19] provides excellent simulation for Tor but has no I2P support. Ahmed et al. [20] package a 5G core as a reproducible cyber range, establishing that the reproducibility ethic is achievable for complex network systems. No equivalent exists for I2P on the unmodified reference router in a fully isolated, ethics-safe environment.

3. The G ARLIC - IN - A -B OX Emulator G ARLIC - IN - A -B OX runs a complete I2P network inside a single machine. It stands up dozens of real routers, wires them into a private overlay that mirrors the live network’s structure, and gives the operator full observational control over every router, tunnel, and peer. Three properties drove its design. Fidelity: it runs the unmodified Java I2P reference implementation, not a model of it, so peer selection, tunnel construction, NetDB behaviour, and transport handshakes are the protocol’s own. Isolation: the network is closed by construction, which serves ethics and repeatability at once, since it can neither leak into the live network nor be perturbed by it, and an experiment reproduces months later. Deployability: it installs from one Debian package with source available [21], launches through a graphical interface, and rebuilds reproducibly from a single topology file, without the operator needing to know namespaces or I2P internals.

3.1. Architecture and Per-Router Isolation The reference deployment runs on the University of Cincinnati Ohio Cyber Range Institute (OCRI), inside a nested virtualization stack (Fig. 2) whose innermost Ubuntu 24.04 guest hosts the emulator with 48 GB RAM, twelve virtual CPUs, 200 GB disk, and a bridged adapter. The stack imposes no functional restriction, since namespaces need only kernel network-stack access; it fixes only an upper memory bound.

Client Tunnel Peers

DHT (Kademlia) Fast Peer

Database Store / Lookup

Physical server → VMware ESXi (Type-1) Windows Server 2019 VM Peer Profile Groups

Oracle VirtualBox (Type-2) Router Profiling in local Database

High Capacity Peer

Figure 1. I2P peer-selection ecosystem [14]. A new router bootstraps via the public reseed mechanism, accumulates peer profiles in its local DHT-backed database, and selects tunnel hops from the fast and highcapacity peer groups produced by the ProfileOrganizer. G ARLIC - IN - A -B OX replicates this full cycle in an isolated environment without the external reseed dependency.

Ubuntu 24.04 guest ns r1

ns r2

48 GB RAM, 12 vCPU, 200 GB ns r3

···

ns r50

unmodified Java I2P ×50

Figure 2. Deployment stack. Fifty unmodified Java I2P routers run as isolated network-namespace processes inside a single Ubuntu guest.

Each router ri occupies its own Linux network namespace, i2pns-ri, joined to an emulated subnet by a veth pair and a bridge, letting many real routers coexist on one host without interference. Each carries its own routing table, a stable IP from the topology, and its own NTCP2 and SSU2 ports. Inter-router packets traverse the host loopback at memory-copy speed and never reach a physical interface. Per-router state lives under a predictable tree, ˜/i2p-testnet-50/ri/{config,data,logs}, read directly by the measurement pipeline. Isolation in I2P matters not at the binary layer but at the identity, NetDB, tunnel, and peer-state layer; separating all of it per router lets one installation behave as fifty independent participants.

3.2. Scale and Geographic Realism The reference network runs fifty routers across five locations, France, Germany, Japan, Lebanon, and the United States, with five floodfills forming the NetDB backbone. The geography is functional: I2P weighs country of origin when building tunnels and ranks routers into bandwidth tiers, so G ARLIC - IN - A -B OX assigns each a public-style IP from a distinct address family and a country-appropriate bandwidth profile, engaging that same selection logic. Fifty routers is enough for it to bite, giving floodfill selection real diversity, making tunnel paths non-trivial, and letting churn drop several routers at once. Scale is bounded by the memory available to the guest, not by the platform, so a larger allocation raises the count; Section 5.3 reports behaviour as that bound is approached.

3.3. Bootstrapping Without Signed Reseed Standard I2P bootstraps from cryptographically signed .su3 bundles served by registered reseed hosts (the reseed

path in Fig. 1) [8], [14]. A private network cannot produce those bundles, and a router below its known-peers threshold loops on the public reseed servers, the very hosts an isolated network must never touch. G ARLIC - IN - A -B OX resolves this with a two-phase filesystem bootstrap that replaces the network reseed with a local one. Phase A, at deploy time, writes each router’s identity and publishes its RouterInfo into every peer’s netDb directory, so each router starts past the minimum-known-peers threshold and never seeks an external reseed. Phase B, at runtime, runs a timer that collects the fresh RouterInfo files routers generate and redistributes them across the fleet, which I2P’s directory watcher ingests live without a restart, keeping a current shared peer view from the local filesystem alone. The network reaches full emergence with no external contact. Algorithm 1 gives the full sequence.

3.4. Containment and Isolation Guarantee Isolation is structural, enforced by three independent mechanisms. The local bootstrap removes the only reason a healthy router would contact an outside host; each router’s

Algorithm 1 Isolated G ARLIC - IN - A -B OX deployment Require: Topology T = (R, F, G): routers R, floodfills F ⊆ R, region map G 1: create bridges and subnets for all blocks in T 2: for each router ri ∈ R do 3: create namespace i2pns-ri, veth pair, assign IP 4: generate identity keypair; write router.config 5: set floodfill flag if ri ∈ F ; set bandwidth from G(ri ) 6: for each router ri ∈ R do ▷ Phase A 7: copy {RouterInfoj : j ̸= i} into ri/data/netDb 8: start all routers; arm cross-pollination timer (Phase B) 9: wait ≈ 25 min, undisturbed

namespace has no default route to a physical interface, only the internal bridge, so no path off the machine exists; and all addressing comes from the topology on virtual interfaces, so packets are copied through host memory and never reach hardware. The virtualization layers add separation, but the guarantee holds at the namespace layer without them. We confirmed this empirically: with the full network building tunnels, a capture on the guest’s physical adapter showed no I2P traffic to any external address, while a capture on the internal bridge showed the expected NTCP2 and SSU2 exchange. No public reseed host, floodfill, or offtopology address appeared, and the network sustained hours of measurement without a single packet crossing outward. G ARLIC - IN - A -B OX is therefore a true, high-fidelity I2P, real software producing real behaviour, entirely within a box. G ARLIC - IN - A -B OX is run by a PyQt5 application (Fig. 3). The Fleet screen provides router cards that show peer and tunnel counts, reachability, uptime and console access. In the Topology Builder (Fig. 4), locations, subnets, and router and floodfill counts are validated to create the sole topology JSON that drives deployment. The Topology screen (Fig. 5) provides the live graph visualization with the floodfills shown as well. The Network Map screen (Fig. 6) maps the routers geographically with live overlays and floodfill backbone. The Scenarios screen (Fig. 7) runs churn, attack and resilience templates, and the Measurements screen starts and exports fleet-wide measurements. The header polls aggregated counters every eight seconds. As all the state is read from the router directory trees, the measurements are based on the router state, not inference, providing a ground truth.

4. Deployment The study deploys fifty routers across five locations; France, Germany, Japan, Lebanon, and the United States. It uses ten routers per location, each location occupying its own /27 subnet with one floodfill. A generated GeoIP file binds each subnet to a country code, and every router carries a matching bandwidth profile, so I2P treats the network as geographically diverse and applies its hop-per-addressblock cap [14] to every tunnel built. This layout is a study configuration rather than a platform limit: the Topology Builder (Fig. 4) generates arbitrary locations, subnets, and

Figure 3. G ARLIC - IN - A -B OX fleet dashboard. All 50 routers are ACTIVE. Router 10 (the victim, highlighted) is selected; its detail pane confirms Floodfill: false, Location: Beirut, Lebanon, IP: 45.10.1.11, and 49 known peers.

Figure 6. Network Map view placing all 50 routers on a world map across five geographic locations (France, Germany, Japan, Lebanon, USA). The floodfill backbone (dashed lines) connects the five floodfill routers. Router 10, selected here, shows live measurement-stability data and observed-path evidence in its popup panel.

Figure 4. Topology Builder. The table specifies five locations, five subnets, 50 routers, and five floodfills. The generated topology JSON (shown at bottom) is the single input to deployment.

Figure 7. Scenario configuration panel for a churn experiment: random stop/start events on non-floodfill routers, with adjustable intervals (15– 25 s), downtime (10 s), and event count (10). The Setup, Execution, and Campaign subtabs structure the full experiment lifecycle.

45.10/27 (LB)

counts with a matching GeoIP mapping. Fig. 8 shows the result: five subnet clusters joined by bidirectional namespace interconnects, each cluster’s floodfill replicating the network’s netDb distribution. The victim r10 and attackers r45 –r49 sit in separate clusters, so every tunnel the attack touches crosses subnet boundaries and exercises the addressdiversity constraint.

r1

91.80/27 (DE)

185.20/27 (FR)

r11

r21

r9 r10

r12

r13

r22

r41

r31 r45 r32

r23

r46

r47

r33 r48

r49

23.10/27 (JP) 150.20/27 (US) floodfill

victim

attacker

regular

Figure 8. Logical topology of the fifty-router deployment. Five subnet clusters span five geographic locations. The five attackers (r45 –r49 ) share the US cluster; the victim (r10 ) sits in a separate cluster.

5. Testing Figure 5. Live topology graph of the fifty-router network after full emergence. All 50 nodes are active (green). The five floodfill routers (r1 , r11 , r21 , r31 , r41 ) appear with a bright outer ring. Every node shows live peer counts.

5.1. A Two-Stage Model of Peer Selection Tunnel participation unfolds in two stages. In selection, the victim decides which peers are eligible to appear in its

tunnels; in delivery, an eligible peer must accept the build request and actually relay traffic. Keeping the stages apart is what lets the results be read precisely, since the attack we study succeeds at selection and then exposes what delivery additionally demands. Definition 1 (Peer profile). Let v be a victim router and Pv its known peers. For each p ∈ Pv , the profile is a tuple πv (p) = (ŝ, ĉ, β s , β c , h), where ŝ, ĉ are measured speed and capacity, β s , β c are stored bonuses, and h is the tunnel history. The ProfileOrganizer adds each stored bonus to the measured estimate, sv (p) = ŝv (p) + βvs (p), cv (p) = ĉv (p) + βvc (p),

(1) (2)

and admits to the preferred set every peer that clears both thresholds,  Fv = p ∈ Pv sv (p) ≥ τvs ∧ cv (p) ≥ τvc . (3) The thresholds τvs , τvc follow high percentiles of the score distributions the victim observes. Definition 2 (Selection probability). For a tunnel of hop length ℓ, a peer p ∈ Fv appears in any given tunnel of v with probability Pr[p ∈ Tv ] ≈

ℓ , |Fv |

(4)

subject to address-diversity constraints, and zero if p ∈ / Fv . Entering Fv is the adversary’s goal at selection, and Eqs. (1) and (2) expose two independent routes. The behavioral lever raises the measured terms ŝ, ĉ through genuine performance: advertising high bandwidth, accepting builds quickly, holding uptime. The injection lever writes large bonuses β s , β c directly, skipping measurement altogether. Theorem 1 (Injection guarantees eligibility). If βvs (a) > τvs and βvc (a) > τvc , then a ∈ Fv for any ŝv (a), ĉv (a) ≥ 0. Proof. Substituting into (3): sv (a) = ŝv (a) + βvs (a) > τvs and cv (a) = ĉv (a) + βvc (a) > τvc , hence a ∈ Fv . Eligibility is not participation. A peer in Fv must still accept the build and carry traffic. Writing αv (p) for the rate at which p agrees to join tunnels proposed by v , the expected volume through p is E[tunnels through p] ∝ Pr[p ∈ Tv ] · αv (p).

(5)

TABLE 1. P ROFILE FIELDS USED FOR MEASUREMENT Field

Role in selection

speedBonus

injected bonus β s (stage one) injected bonus β c (stage one) measured speed ŝ accepted builds (delivery proxy) rejected builds (delivery proxy) response latency

capacityBonus tunnelPeakThroughput tunnels.lifetimeAgreedTo tunnels.lifetimeRejected tunnelCreateResponseTime

5.2. Measurement Methodology I2P writes the very quantities of Section 5.1 to disk. For each known peer the victim keeps a gzipped file, rv /data/peerProfiles/pX /profile-hash.txt.gz, holding the fields in Table 1, so reading these files exposes the selection state faithfully and without modifying the router. A live router holds profile updates in memory and flushes them only on graceful shutdown. To take a consistent snapshot we stop the victim, which forces the flush, copy its peerProfiles tree and netDb, and restart it; each flush yields 46 to 49 profiles. Profiles are keyed by I2P identity hash rather than emulator index, so we rebuild the mapping from the victim’s own netDb: each attacker advertises a known topology IP, and scanning RouterInfo files for that IP yields the hash from the filename. We recompute this mapping from live state on every trial. This protocol was learned the hard way. An early pilot compared a fresh run against a victim profile that still held an injection from an earlier trial, and the 9999 → 9999 baseline that resulted was an artefact rather than a measurement. Every trial now passes an anti-contamination gate that confirms all attacker bonuses read zero before it proceeds. Algorithm 2 gives the per-trial procedure in full. Algorithm 2 One reputation-attack trial Require: victim v , attackers A, controls C 1: clean: revert attacker configs; zero βvs (a), βvc (a) for all a ∈ A; settle 10 min 2: baseline: stop v ; snapshot profiles; restart v 3: gate: assert βvs (a) = 0 ∀a ∈ A, else abort 4: attack: apply behavioral config to A; stop v ; write β s , β c ← 9999; start v ; settle 10 min 5: attack snapshot: stop v ; copy profiles; restart v 6: analyze: resolve hashes; compute mA , mC , ρ(m) per Table 1

An adversary that maximises Pr[p ∈ Tv ] while αv (p) stays low gains little, and Section 5.3 measures both factors to show exactly that. For each profile metric m we report the attacker-to-control ratio mA ρ(m) = , (6) mC

Each trial runs end to end without pause, because a pause lets the coalescing timer overwrite the injected values; we observed this in early work and treat it as the main reliability hazard.

averaged over trials, with values above one favouring the adversary.

The evaluation spans five independent trials. Router r10 (IP 45.10.1.11) is the victim throughout. Five regular non-

5.3. Evaluation

Selection vs. delivery: attackers are chosen more but reject 3.4×

TABLE 2. R ESOURCE FOOTPRINT OF THE FIFTY- ROUTER DEPLOYMENT

RAM (measured) Disk (testnet tree) Emergence time Single-host ceiling

≈ 417 MB ≈ 9 MB — —

Tunnels agreed-to

Fleet (50) ≈ 20.9 GB ≈ 457 MB ≈ 25 min ≈ 90 routers

TABLE 3. M EAN ± STD ACROSS FIVE TRIALS ( ATTACK CONDITION ). BASELINE BONUSES ARE ZERO BY THE GATE . Metric

speedBonus capacityBonus tunnelPeakThroughput lifetimeAgreedTo lifetimeRejected responseMs

Attackers

Controls

9999.0 ± 0.0 9999.0 ± 0.0 0.127 ± 0.000 10.76 ± 0.20 265.8 ± 21.2 21.71 ± 4.82

0.0 ± 0.0 0.0 ± 0.0 0.210 ± 0.072 7.80 ± 1.84 77.0 ± 16.5 16.52 ± 1.29

floodfill routers in a separate subnet cluster, r45 through r49 , act as attackers, and five matched regular routers, r42 through r44 with r32 and r33 , serve as controls. The anticontamination gate (Algorithm 2, line 3) passed in all five trials, so every baseline began with attacker bonuses at zero. Table 2 reports the footprint from live systemd cgroup readings. Memory is the binding resource. At 417 MB per router the fleet settles near 21 GB, leaving the 48 GB guest ample headroom, enough in principle for nearly ninety routers. We stopped at fifty because five geographic locations already made the topology representative, not because of that ceiling. Across all five trials the injected values held exactly. Attacker speedBonus and capacityBonus read precisely 9999 in the victim’s profiles with no cross-run variance (Fig. 9), while the controls remained at zero. Table 3 gives the full breakdown. This is Theorem 1 in practice: once a bonus clears the threshold, membership in Fv follows on the unmodified router every time.

speedBonus value

10000

Injected speed bonus (N=5) 9999

= 0 (deterministic)

8000 6000 4000 2000 0

0

Attackers

Controls

Figure 9. Injected speedBonus in the victim’s profiles, five trials. The effect is perfectly repeatable (σ = 0); controls are untouched.

Eligibility carried through into selection outcomes. The attackers drew 10.76 ± 0.20 lifetime build requests on aver-

10 8 6 4 2 0

300

10.76

7.8

Attackers

Controls

count (lifetime)

Per router

count (lifetime)

Resource

Tunnels rejected 265.76

200 100 0

77.04

Attackers

Controls

Figure 10. Delivery stage. Attackers receive more build requests (left) but reject a larger fraction (right), illustrating the separation between the two stages.

age against the controls’ 7.80 ± 1.84, a ratio ρ(agreedTo) = 1.38 (Fig. 10, left), matching what Eq. (4) predicts: the victim invites the adversary into its tunnels at 1.38× the rate of comparable peers. Delivery behaved differently, and the two-stage separation shows here plainly. Although selected more often, the attackers accepted far fewer requests: their lifetime rejections reached 265.8 ± 21.2 against the controls’ 77.0±16.5, giving ρ(rejected) = 3.45 (Fig. 10, right). Equation (5) explains why. The aggressive behavioral configuration we applied, maximising advertised bandwidth and the participating-tunnel limit, pushed the attackers into a regime where they declined most builds. Selection succeeded completely; delivery demanded conditions the configuration did not meet. Compromising the selection criterion is therefore a necessary step toward traffic interception, not a sufficient one. The behavioral lever proved weak under light load. Attacker throughput measured 0.127 ± 0.000 KBps, below the controls’ 0.210 ± 0.072 KBps, for ρ(throughput) = 0.60 (Fig. 11). Advertising a 16 MB/s bandwidth class did not lift the victim’s measurement, because measured throughput reflects traffic actually carried and testbed traffic is light: the lever moved β but not ŝ. Injection is thus the effective component here, and whether the behavioral lever behaves differently on the loaded network is exactly what the emulator is suited to study. Fig. 12 collects ρ(m) across all metrics. Selection moves strongly for the adversary while delivery does not follow of its own accord, and together the trials locate the structure of the attack with the precision the platform was built to provide.

6. Cybersecurity and Cyberwarfare Training A CISA advisory issued in April 2026 characterised state-sponsored covert relay ecosystems as a strategic national security priority [6]. ORB variants used by groups such as APT28 and Volt Typhoon adapt peer-selection and relay-management techniques drawn from conventional anonymity networks including I2P [18]. Training cyber operators to recognise and disrupt these architectures therefore

Measured peak throughput (N=5) advertised 16 MB/s had no effect

0.25

Red team launches

0.21

0.20 KBps

Deploy network

Blue team monitors

0.15

0.127

0.10

no

detected?

0.05

Escalate scenario

yes

0.00

Debrief and defend

Attackers

Controls Apply and rerun

Figure 11. Measured peak throughput, five trials. Advertising a high bandwidth class did not raise the attackers’ measured throughput above the controls.

Attacker / Control ratio

3.5

Attacker-to-control ratio across behavioural metrics (N=5) 3.45×

3.0

Because a fresh testnet emerges in under thirty minutes, the cycle runs multiple times in a single session.

2.5 2.0 1.5

1.38×

1.31×

1.0

6.3. Curriculum and Operator Readiness

0.60×

0.5 0.0

Figure 13. Red-team and blue-team training cycle supported by G ARLIC IN - A -B OX . A detected anomaly leads to debrief and defence; an undetected one escalates the scenario and repeats.

agreed-to

rejected

throughput

response ms

Figure 12. Attacker-to-control ratios ρ(m), five trials. Values above the dashed line (ρ = 1) favour the adversary.

requires hands-on exposure to the real protocol mechanics, not classroom abstractions. G ARLIC - IN - A -B OX provides this substrate.

6.1. Attack Scenario The Scenarios panel provides configurable attack and resilience templates, each specifying an attacker set, scenario type, timing parameters, and event count. Templates can run from the interface or headlessly from a script. The current library includes: reputation injection (studied in this paper); Sybil flooding, which bursts attacker RouterInfos to study netDb poisoning and floodfill recovery; bandwidth inflation, which tests whether advertised capacity alone wins the high-capacity tier; and churn, which stops or degrades routers to measure tunnel-rebuild latency and anonymity-set reduction under attrition.

6.2. Red-Team and Blue-Team Exercises The platform supports structured two-team exercises (Fig. 13). A red team launches a scenario. A blue team monitors fleet telemetry, inspects profiles and logs, and tries to locate the anomaly. A debrief follows, in which the team proposes a defence and retests it against the same scenario.

The platform supports a short teaching module. One natural progression begins with I2P architecture and netDb mechanics explored through the live router consoles, moves to peer selection and the reputation model with a profileinspection exercise, then has students run the provided scenarios and interpret the output for themselves, and finally asks them to design a countermeasure and test it. Because the Scenario History view records every run with its parameters and outcomes, a session can be revisited during after-action review. For operator readiness the value is more specific. The platform offers a safe, protocol-authentic setting in which the peer-selection mechanics that ORB variants inherit from I2P can be observed live rather than in abstraction. Working from real I2P router consoles, an operator can watch a reputation-poisoned peer climb in the victim’s profile, see its selection probability rise as a result, and compare how its traffic signature in the logs departs from that of a legitimate peer. To the best of our knowledge, no existing tool offers this capability on an unmodified I2P router.

7. Lessons Learned Building and operating G ARLIC - IN - A -B OX surfaced several practical lessons that shaped the final design, and that others working with isolated I2P testnets are likely to encounter. Bootstrap is the most critical design choice. Strip out the filesystem seed and every router drops straight into a reseed loop. Our early prototypes leaned on the public reseed servers, and the result was always the same: a network in which a few routers never managed to integrate. Pairing

the Phase A seed with the Phase B cross-pollination timer closes off that failure entirely. Emergence must be uninterrupted. If the network is paused while routers are still building their first tunnels, peer profiles and netDb entries are left half-expired. Routers stopped and restarted mid-emergence returned with markedly lower peer counts than those left undisturbed. The twenty-five-minute window, then, is no safety margin; it is the floor for a healthy fleet. Profile flush timing is an experimental variable. A running router keeps all of its profile data in memory, so reading the on-disk profiles while it runs simply returns nothing. Our early experiments assumed the on-disk copies were live and were quietly rewarded with false negatives. Stopping the router gracefully and only then snapshotting is the one approach we found reliable. Clean-baseline discipline is non-negotiable. One pilot compared an attack snapshot against a baseline that still carried injected values from an earlier run; the 9999 → 9999 difference came out to zero and the trial reported no effect at all. The anti-contamination gate (Algorithm 2, line 3) exists precisely to catch this, and it has to run on every trial. Live cgroup measurement corrects static estimates. Our first per-router memory figure, 257 MB, came from a partial reading and was simply wrong. The live systemd cgroup measurement put it at 417 MB, 62% higher. The lesson generalises: measure resource use on the running system, not from static profiling tools or back-of-envelope estimates.

8. Discussion and Future Work Splitting the attack into two stages is what keeps the result unambiguous. An adversary that reaches Fv has defeated the selection criterion outright; whether that success converts into carried traffic is a separate question with its own conditions. The practical upshot is that a defence mounted at the selection layer confronts the prerequisite shared by a broad class of interception attempts, and does so at the more tractable of the two points. The model also points to a simple defence. An injected bonus sits orders of magnitude above anything legitimate observation would produce, so a router that checks a stored bonus against the distribution of its own measurements for that peer could flag the mismatch and discount the value, leaving peers that earned their standing untouched. Quantifying this defence, including its false-positive cost, is a natural next step. Several other directions follow. Instrumenting a router to emit authoritative tunnel-hop events would measure stage-two delivery directly, rather than through the proxies we rely on now. Spreading the deployment across multiple hosts over an encrypted mesh would push past the single-machine ceiling of roughly 90 routers. A dedicated traffic generator would exercise the behavioral lever under realistic load, where its effect may look quite different. Finally, the scenario library invites expansion: netDb eclipse and floodfill corruption are two obvious ORB-relevant mechanics still to be covered.

9. Conclusion We presented G ARLIC - IN - A -B OX, an installable emulator that runs unmodified I2P routers at useful scale, with a control interface, a scenario engine, and a filesystembased measurement pipeline. The platform eliminates the reproducibility barrier that has limited I2P security research and provides a protocol-authentic training environment for cyber-defence exercises on anonymous overlay threats. A five-trial evaluation of a reputation attack showed deterministic success at the selection stage and precise characterisation of the delivery stage. We release the platform and its measurement scripts so others can reproduce the study, test the defensive signal we identify, and build on the scenario library for their own research and training.

Acknowledgment The authors thank the MIRAGe-UC Laboratory and the UC-OCRI (http://mirage-uc.org/) for computing resources.

References [1]

S. A. Muntaka and J. Bou Abdo, “Systemic flaws in the invisible internet project: Analysis of exploitable design choices,” 2026.

[2]

Google Cloud: Mandiant Services, “IOC extinction? China-nexus cyber espionage actors use ORB networks to raise cost on defenders,” [Online]. Available: https://cloud.google.com/blog/topics/ threat-intelligence/china-nexus-espionage-orb-networks, 2024, accessed: 18 May 2026.

[3]

MITRE ATT&CK, “APT28,” [Online]. Available: https://attack.mitre. org/groups/G0007/, 2026, accessed: 18 May 2026.

[4]

MITRE ATT&CK Groups, “Volt Typhoon,” [Online]. Available: https://attack.mitre.org/groups/G1017/, 2026, accessed: 18 May 2026.

[5]

The MITRE Corporation, “SPACEHOP activity,” [Online]. Available: https://attack.mitre.org/campaigns/C0052/, 2025, accessed: 18 May 2026.

[6]

Cybersecurity and Infrastructure Security Agency (CISA), “Alert (AA26-113A): Defending against China-nexus covert networks of compromised devices,” [Online]. Available: https://www.cisa.gov/ news-events/cybersecurity-advisories/aa26-113a, April 2026, last accessed 18 May 2026.

[7]

S. A. Muntaka and J. Bou Abdo, “Optimizing anonymity and efficiency: A critical review of path selection strategies in tor,” in 2025 IEEE/ACS 22nd International Conference on Computer Systems and Applications (AICCSA). IEEE, 2025, pp. 1–8.

[8]

The I2P Project, “I2P technical documentation,” https://geti2p.net/en/ docs, 2024, accessed: 2024.

[9]

J. Bou Abdo and L. Hossain, “Modeling the invisible internet,” in International Conference on Complex Networks and Their Applications. Springer, 2023, pp. 359–370.

[10] S. A. Muntaka, J. Bou Abdo, and L. Hossain, “Bridging the epistemic gap in the invisible internet: Extended mathematical modeling and empirical characterization of i2p topology,” 2026. [Online]. Available: https://arxiv.org/abs/2607.23825 [11] The Invisible Internet Project (I2P) , “Peer profiling and selection,” https://geti2p.net/en/docs/how/peer-selection, 2024, accessed: 2024. [12] L. Schimmer, “Peer profiling and selection in the I2P anonymous network,” in PetCon 2009.1. Technische Universität Dresden, 2009, pp. 59–70.

[13] M. Herrmann and C. Grothoff, “Privacy-implications of performancebased peer selection by onion-routers: A real-world case study using I2P,” in Proc. 11th Privacy Enhancing Technologies Symposium (PETS). Springer, 2011, pp. 155–174. [14] S. A. Muntaka, J. Kropczynski, J. Bou Abdo, and M. Ozer, “Geographic patterns in I2P peer selection: An empirical network topology analysis,” Internet Technology Letters, vol. 9, no. 4, p. e70313, 2026. [15] J. P. Timpanaro, I. Chrisment, and O. Festor, “Monitoring the I2P network,” INRIA, Technical Report, 2011. [16] C. Egger, J. Schlumberger, C. Kruegel, and G. Vigna, “Practical attacks against the I2P network,” in Proc. 16th Int. Symp. on Recent Advances in Intrusion Detection (RAID). Springer, 2013, pp. 432– 451. [17] S. A. Muntaka and J. Bou Abdo, “Resilience of the invisible internet project: A computational analysis,” Internet Technology Letters, vol. 8, no. 5, p. e70119, 2025. [18] S. A. Muntaka, J. Bou Abdo, K. Akanbi, S. Oluwadare, F. Hussein, O. Kornyo, and M. Asante, “Mapping the invisible internet: Framework and dataset,” Data in Brief, p. 112175, 2025. [19] R. Jansen and N. Hopper, “Shadow: Running Tor in a box for accurate and efficient experimentation,” in Proc. Network and Distributed System Security Symposium (NDSS), 2012.

[20] A. H. Ahmed, T. Dreibholz, F. I. Michelinakis, and T. Čičić, “Open 5G Testbed: A cyber range platform for security research,” in 2025 Annual Computer Security Applications Conference Workshops (ACSAC Workshops). IEEE, 2025, pp. 579–586. [21] S. A. Muntaka, “i2p-emulator: A controlled I2P testnet emulator,” https://github.com/abksiddique/i2p-emulator, 2026, mIT License. Accessed: 2026.

Artifact Availability The emulator and measurement pipeline are released as open-source software (MIT License) at https://github.com/ abksiddique/i2p-emulator.

LLM Usage Statement LLMs were used for editorial purposes in this manuscript, and all outputs were inspected by the authors to ensure accuracy and originality.

Related documents

• Garlic in a Box: I2P Network Emulator#1456827
• Detecting Data Exfiltration through I2P Anonymity Networks: A Two-Phase Machine Learning Approach#216776
• Shadow Libraries and Pirate Infrastructures#261140
• Physical Side-Channel Attacks on Edge LLMs: Extracting Output Tokens and User Prompts#1324816
• ClawGuard: Out-of-Band Detection of LLM Agent Workflow Hijacking via EM Side Channel#160726