mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-05 19:18:25 +00:00
Johnathan Corgan
40c67abbe6
Five files conflicted and each needed a different call, because the two lines had rewritten different halves of the same code. The handshake handler takes next's version whole. master's entire change there was three comment blocks and one widened debug_assert, and the assert names HandshakePhase::ReceivedMsg1, a variant next's XX rewrite does not have. Nothing semantic was dropped. The peer reaper takes master's: reap_peers_on_transport is new and its route_link_dead doc now describes both callers, which is true on this line too. The ethernet transport takes master's binder rewrite with next's wire format re-applied on top. The send path, the receive path and the frame tests merged to the 4-byte header on their own, but three sites are new in master's rewrite and had never seen it: the Binding default and both arms of the binder's MTU calculation still subtracted 3. The transports snapshot fixture moved with them, 1499 to 1496, and that single field was the whole diff. Beacons carry no pubkey here, so local_pubkey leaves the transport, its binder context and the node's transport construction with it. The changelog keeps both sides' entries, with master's Added subsection lifted back out of Changed where the merge had left it. Two tests do not come across. a_transient_msg2_failure_keeps_the_link_for_ the_retry and its restart-path sibling assert that the machine rests at ReceivedMsg1. This line's nearest state is SentMsg2, and it means something else: the inbound leg parks there awaiting msg3, where on the other line that phase was the last stop before promotion. Renaming it would produce a test that passes without exercising the deferral. The behaviour they guard did merge and sits in the transient arm of the msg2 send failure; what is missing is coverage shaped for this handshake, which is tracked separately. The two connected-socket tests did come across. Their helper took the responder's session straight after msg2, which is an IK assumption; it now runs msg3 as well. Both pass here and both go red when the clear is removed or made unconditional. The test-harness fixes arrive through master rather than as follow-ups here, so this line never carries the versions that failed: the interface-binding suite's veth naming, and the chaos veth restore, random streams, settle wait, netem restore and shared down-node set.
FIPS Design
Architectural and protocol-level explanations for FIPS — the why and the how behind the wire and the system. For wire formats and configuration keys, see reference/. For task recipes, see how-to/. For end-to-end lessons, see tutorials/.
Reading Order
Start with fips-concepts.md for the novice-friendly framing of what FIPS is and why, then move to fips-architecture.md for the protocol stack, identity model, and two-layer encryption walkthrough. From there, follow the protocol stack from bottom to top. After the stack, fips-mesh-operation.md explains how the pieces work together at runtime. Cross-cutting and supporting documents cover specific subsystems in detail.
Foundations
| Document | Description |
|---|---|
| fips-concepts.md | What FIPS is, why it exists, mental model |
| fips-architecture.md | Protocol stack, identity, two-layer encryption |
| fips-prior-work.md | Designs and protocols FIPS builds on |
Protocol Stack
| Document | Description |
|---|---|
| fips-transport-layer.md | Transport layer: datagram delivery over arbitrary media |
| fips-mesh-layer.md | FIPS Mesh Protocol (FMP): peer authentication, link encryption, forwarding |
| fips-session-layer.md | FIPS Session Protocol (FSP): end-to-end encryption, sessions |
| fips-ipv6-adapter.md | IPv6 adaptation: TUN interface, DNS, MTU enforcement |
| fips-native-api.md | Native datagram API: pubkey-addressed flows over FSP, and what it is instead of the TUN path |
Cross-Cutting
| Document | Description |
|---|---|
| fips-mmp.md | Metrics Measurement Protocol (link + session) |
| fips-mtu.md | Path MTU model, encapsulation overhead, PMTUD |
| fips-security.md | fips0 interface threat model and default-deny baseline |
Mesh Behavior
| Document | Description |
|---|---|
| fips-mesh-operation.md | How the mesh operates: routing, discovery, error recovery |
| fips-nostr-discovery.md | Optional Nostr-mediated peer discovery and UDP NAT hole-punch |
| port-advertisement-and-nat-traversal.md | Nostr-signaled port advertisement and UDP NAT-traversal protocol; generic, with FIPS as an example implementation |
Deeper Dives
| Document | Description |
|---|---|
| fips-spanning-tree.md | Spanning tree algorithms: root discovery, parent selection, coordinates |
| fips-bloom-filters.md | Bloom filter properties: FPR analysis, size classes, split-horizon |
| spanning-tree-dynamics.md | Spanning tree walkthroughs: convergence scenarios, worked examples |
Adjacent Components
| Document | Description |
|---|---|
| fips-gateway.md | fips-gateway service: outbound (LAN-to-mesh) DNS-proxy + virtual-IP NAT and inbound (mesh-to-LAN) port-forwarding, sharing one nftables table |