Status

Open Questions

What is still unsettled. These are tracked deliberately so they are decided on purpose, not by default. Several are parameters we intend to set empirically rather than argue about up front.

Authenticated time source

pinned

Public NTP is spoofable, and since time is the shared state behind address derivation, controlling a client's clock is a denial of service with no cryptography broken.

Direction: an operator-run time service whose responses are root-signed, so spoofing a client's clock requires the root key — the same anchor everything else chains to. The security is in the signature, not in obscuring the epoch.

Rejected sub-idea: using an exotic or alternate calendar (e.g. Hijri) as the time base. It is obfuscation, not defense — zero attacker cost for someone holding the client binary — and a lunar calendar has no single canonical algorithm, which would import a real interoperability problem. The good half (a signed, operator-run epoch, which the epoch field already parameterises) is kept; the obfuscation half is dropped.

Interim mitigation: a persisted monotonic floor rejecting backward clock jumps. Already speced into Module 2.1.

Bucket duration

unsettled

Candidate default is 1 hour. Shorter means more rotation and less exposure per address, at the cost of tighter clock requirements. It is a manifest tunable, so it costs nothing to change later — to be set empirically.

Default tunable values

empirical

N (cells per device), rotation rate, mean lifetime, low-water threshold, skew, slots per cell. All manifest policy. Intended to be tuned against real operating behaviour during development, not decided in the abstract now. Starting points: N = 10, skew = 1, ~90-day lifetime, ~100 total cells.

Cross-cell routing

unsettled

How traffic between devices on different cells is carried: cell-to-cell relay (preferred — clients hold fewer connections, the relaying cell sees only ciphertext + routing header) versus client multi-homing (clients connect to several cells directly). See blast radius.

Isolation model on a single machine

settled for v1

Decided: in v1, a cell's addresses are additional IPv6 addresses on one kernel. They are a rotation-and-availability mechanism, not a per-address security boundary — the security boundary is the machine (the cell). Client redundancy comes from holding secrets for N different machines, which is structural. Stronger per-address isolation (VMs, namespaces) is a possible future version, not v1.

Underlying network isolation

external

The network runs on its own isolated substrate — a separate operator-built tool, not part of Zajil. Zajil assumes but does not implement it, which is why public IPv6 availability is a non-concern.