RPKI and BGP Security
RPKI is usually taught from the validator's side, and this module deliberately teaches the other half: what the router actually receives and what it does with it. The answer starts with a deletion — the router never sees a signature. All of RPKI's cryptography happens in a relying-party cache, and what crosses the RTR session is a flat tuple whose entire shape is visible in FRR's own printer: a prefix, a min_len..max_len range, and an origin ASN. That makes max_len a real control rather than a detail, because a ROA is a length RANGE and a max_len longer than the prefix pre-authorises every sub-prefix inside it — and since a more-specific wins best-path on length alone, loose max_len is the one configuration in which origin validation returns VALID for the attack. The deeper point is what origin validation is checking: rpki_validate_prefix() takes the origin AS out of the RECEIVED AS_PATH, walking to the last segment and reading the rightmost ASN, an attribute nothing in this tree authenticates. RFC 6811 names three outcomes and the implementation has four, with the extra one declared first and therefore sitting at zero — so every bare `return 0` in that function is a silent 'no opinion' that consumers treat as permission: no extended community attached, nothing printed by the show paths, route installed. That is why RPKI fails open and looks healthy doing it. An `rpki` block with no cache server configured enables nothing at all, in FRR's own words 'Prefix validation is off.', and the session still comes up. There is also no enforce mode: the only lever the module registers is a route-map match, there is no bestpath flag anywhere in bgpd, and FRR's documentation overclaims a command it never lists while its worked example merely lowers local-preference to 10. Staleness is the subtlest part and its direction is the opposite of the intuitive one — a stale cache does not produce false positives, it produces silence, and nothing in FRR notices, because rtr_is_synced is cleared only at startup and all three RTR timers (600 s retry, 3600 s polling, 7200 s expiry) are handed out to rtrlib and never watched again. Past expiry a prefix that was VALID simply answers NOT_FOUND, per prefix and without a log line. At full-table scale what breaks is not a validator's memory but a single PF_LOCAL/SOCK_DGRAM socketpair, which discards ROA updates rather than queueing them when it overflows and falls back to a bulk revalidation. And beyond the origin there is almost nothing: BGPsec appears nowhere in this tree, so RFC 8205 is a specification rather than a capability here, while what the router does implement is RFC 9234 roles plus Only-To-Customer — which catches route leaks, not forgeries, and is inert until a local role is configured. The one fail-closed knob refuses to peer rather than dropping the route, so it trades reachability for validation. Change the posture, the validation result, the cache's age, the record count, max_len, roles, the BGPsec counterfactual and strict mode, and watch the server-computed cascade across all five sections. Validated against FRRouting 10.6.1 source.
- All current + future modules
- Full kata library
- Progress dashboard + weak area analysis
Cancel anytime. Billed annually.