Add a documentation website, built with Zola

The documentation moves from READMEs into a site in docs/: getting
started, a user guide, operations, a reference, and development pages,
written in the style of network vendors' documentation (docs/STYLE.md).
bin/bgp/README.md and docs/RFCs.md are folded into it.

- A theme of its own in the International Typographic Style, in blues,
  with self-hosted Inter and JetBrains Mono, search over Zola's index,
  dark mode, and no resources loaded from other hosts.
- Example configurations in docs/examples/, shown on the pages and
  checked with `bgp --check` in CI.
- A test that fails when a field of config.proto is missing from the
  configuration reference.
- A CI job that builds the site; Zola fails on broken links and anchors.
- A hardened systemd unit, tried under systemd with kernel routes on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/content/docs/guides/rpki.md

@@ -0,0 +1,167 @@
++++
+title = "RPKI Origin Validation and ASPA"
+description = "Describes route origin validation (RFC 6811) and AS path verification with ASPA, using data received from RPKI caches over the RPKI-to-Router protocol."
+weight = 4
+
+[extra]
+nav = "RPKI and ASPA"
++++
+
+The Resource Public Key Infrastructure (RPKI) allows the holders of IP
+address space and AS numbers to publish signed authorizations. Ferrix uses
+two kinds of authorization:
+
+- A Route Origin Authorization (ROA) specifies which AS can originate
+  routes for a prefix.
+- An Autonomous System Provider Authorization (ASPA) specifies the transit
+  providers of an AS.
+
+RPKI validators, such as Routinator, rpki-client with StayRTR, and FORT,
+retrieve and verify these objects. A router receives the result from the
+validator's cache over the RPKI-to-Router (RTR) protocol (RFC 8210). Ferrix
+includes an RTR client.
+
+## Configuring RPKI Caches
+
+The `rpki` statement specifies one or more RPKI caches:
+
+```textproto
+rpki {
+  caches { address: "127.0.0.1" port: 3323 }
+  caches { address: "192.0.2.53" port: 3323 }
+}
+```
+
+Ferrix connects to one cache at a time, in the order in which they are
+configured, and connects to the next cache if the current one fails. The
+port is required.
+
+Ferrix requests RTR version 2 (draft-ietf-sidrops-8210bis), which includes
+ASPA data. If the cache supports only version 1 or 0, Ferrix uses that
+version. The status page displays the version in use, and displays a
+warning if the version does not include ASPA data.
+
+### Timers
+
+By default, Ferrix uses the refresh, retry, and expire intervals that the
+cache provides. You can configure them as follows:
+
+```textproto
+rpki {
+  caches { address: "127.0.0.1" port: 3323 }
+  refresh_seconds: 3600
+  retry_seconds: 600
+  expire_seconds: 7200
+}
+```
+
+| Statement | Description | Default |
+|---|---|---|
+| `refresh_seconds` | Interval at which Ferrix requests updates from the cache | Cache value, or 3600 seconds |
+| `retry_seconds` | Interval after which Ferrix retries a failed request | Cache value, or 600 seconds |
+| `expire_seconds` | Time after which Ferrix discards data that no cache has confirmed | Cache value, or 7200 seconds |
+
+When the data expires, Ferrix discards it, and no route is considered
+invalid until new data is received.
+
+### Running a Validator
+
+The following command starts Routinator with an RTR server on port 3323:
+
+```bash
+routinator server --rtr 127.0.0.1:3323
+```
+
+> [!CAUTION]
+> The RTR connection uses plain TCP, without authentication or integrity
+> protection. Run the validator on the same host or on a trusted network.
+> An attacker who can modify RTR data can cause valid routes to be
+> rejected, or can disable ASPA verification by negotiating an older
+> protocol version.
+
+## Route Origin Validation
+
+Route origin validation (ROV) compares the origin AS and prefix length of a
+route with the Validated ROA Payloads (VRPs) received from the cache (RFC
+6811). Ferrix validates every route from an EBGP neighbor. The result is one
+of the following states:
+
+- **Invalid**: a VRP covers the prefix, but no VRP authorizes the origin
+  AS for the prefix length. Ferrix rejects the route with the reason
+  `RPKI invalid`, unless the neighbor's import policy includes
+  `accept_rpki_invalid: true`.
+- **Valid**: a VRP authorizes the origin AS for the prefix length. Ferrix
+  accepts the route.
+- **Not found**: no VRP covers the prefix. Ferrix accepts the route.
+
+The validation state does not otherwise affect best path selection.
+
+## AS Path Verification with ASPA
+
+Route origin validation verifies only the origin AS. It does not detect a
+route leak, or a forged AS path that ends with the correct origin AS. ASPA
+verification (draft-ietf-sidrops-aspa-verification, version 24) checks that
+each AS in the path is permitted to advertise the route to the next AS,
+according to the ASPAs of the ASs in the path.
+
+ASPA verification requires the following:
+
+- An RPKI cache that supports RTR version 2.
+- A `role` for the neighbor, because the permitted shape of an AS path
+  depends on the direction from which the route is received. Table 1
+  lists the verification that applies to each role.
+
+| Role | Verification |
+|---|---|
+| `CUSTOMER` | Upstream: the path must consist of customer-to-provider hops only. |
+| `PEER` | Upstream. |
+| `ROUTE_SERVER` | Upstream. The path need not begin with the route server's AS number. |
+| `ROUTE_SERVER_CLIENT` | Upstream. |
+| `PROVIDER` | Downstream: the path can contain upstream hops, one peering hop, and downstream hops. |
+
+Ferrix does not verify the AS paths of routes from a neighbor without a
+role; it performs only route origin validation for them.
+
+The result is one of the following states:
+
+- **Invalid**: Ferrix rejects the route with the reason `ASPA invalid`,
+  unless the neighbor's import policy includes `accept_aspa_invalid: true`.
+  An AS path that contains an AS_SET is invalid. An AS path that does not
+  begin with the neighbor's AS number is invalid, except for routes from a
+  route server.
+- **Valid**: Ferrix accepts the route.
+- **Unknown**: Ferrix accepts the route. Most AS paths are unknown while
+  ASPA deployment is limited.
+
+## Revalidation
+
+RPKI data changes continuously. Ferrix revalidates affected routes when the
+data changes, without requiring the neighbor to readvertise them:
+
+- A route in the routing table that becomes invalid is removed.
+- A route that was rejected as invalid is retained as a **held route**. When
+  the route is no longer invalid, Ferrix accepts it.
+
+The status page displays the number of held routes for each neighbor.
+
+## Verifying RPKI Validation
+
+The status page displays the cache, the RTR version, the age of the data,
+and the validation state of each received route. The HTTP API provides the
+same information at `/api/rpki`. Table 2 lists the related metrics.
+
+| Metric | Description |
+|---|---|
+| `bgp_rpki_vrps{family}` | Number of VRPs in use, by address family |
+| `bgp_rpki_aspas` | Number of customer ASs with an ASPA in use |
+| `bgp_rpki_updates_total` | Number of times the VRPs or ASPAs changed |
+| `bgp_routes_rejected_total{reason="RPKI invalid"}` | Routes rejected by route origin validation |
+| `bgp_routes_rejected_total{reason="ASPA invalid"}` | Routes rejected by ASPA verification |
+
+## Limitations
+
+- Routes from IBGP neighbors and originated routes are not validated.
+- The validation state is not used as a step in best path selection.
+- The AS paths of advertised routes are not verified.
+- RTR is supported over plain TCP only; SSH, TLS, TCP-MD5, and TCP-AO are
+  not supported.