Rayhaan JaufeerallyandClaude Fable 5.1
1f89fb4b13
The first part of RPKI origin validation (RFC 6811): the data and how it gets here. Nothing uses it yet. VrpTable holds the validated ROA payloads and says whether a route is valid, invalid or not found. It is a binary trie in one allocation with a short cut past the first sixteen levels; a lookup against 600,000 entries takes about 40 ns for random addresses. A table is built once and not changed: when the data changes another takes its place. rtr is the RPKI-to-Router protocol's PDUs (RFC 8210, and version 0 of RFC 6810), as bytes and back, without I/O. Lengths are checked from the header, before the rest of a PDU is waited for. The client keeps the table in step with a validator's cache. It asks for everything once and then for changes, when the cache notifies and at the refresh interval. An answer takes effect only when it is complete and consistent. Each update says which VRPs came or went, so that only the routes they cover need looking at again. A cache that fails is retried and the next one tried; the data is used meanwhile, and dropped if no cache confirms it within the expire interval. A cache that speaks only version 0 is spoken to in version 0. Tests: the cases of RFC 6811, a property test of the trie against the plain definition, round-trip and hostile-input properties for the codec, a fuzz target, and the client against a scripted cache. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
BGP
The bgp crate is an implementation of the Border Gateway Protocol, which is used to exchange routing and control plane information between Autonomous Systems.
The aim of this project is to provide a modern, high performance, secure, programmatic and customizable software package that can be useful to network operators, researchers, and people interested in Internet.
Current status.
The project is currently being rewritten from scratch to be more modular and maintainable, as well as to fix deeper issues with the previous implementation.
⚠️ Warning: This is currently a work in progress and not ready for use.
🛣️ Roadmap to v1.0
We aim for the 1.0 release to be functional and stable to operate peering sessions, and to install routes in the Linux Kernel.
- ☐ Implement basic parsers for the fundamental types required
- ✅ Path Attributes from RFC4271
- ✅ Open message
- ✅ Capabilities from RFC4271
- ✅ Update message
- ☐ Notification message
- ✅ Implement scaffolding required to start and configure a server
- ✅ Implement connection logic to establish sessions with peers (passive and active)
- ✅ Routes originated from the configuration, with communities, announced to all peers
- ✅ Read-only HTTP API, status page and Prometheus metrics
- ☐ Implement an efficient data structure for storing prefixes (e.g. Poptrie)
- ☐ Filtering for peer RIB in / out
- ☐ Main / auxiliary RIBs for exchanging routes between peers
Development
CI runs these three on every push, and fails on any warning:
cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
Lints are configured once, under [workspace.lints] in the root Cargo.toml.
unsafe code is forbidden throughout.
cargo test includes property tests: generated messages must survive being
written and read back, and no input, however damaged, may make a parser
panic. They take about a second; for a longer hunt:
PROPTEST_CASES=1000000 cargo test --release -p bgp-packet --test properties
Coverage-guided fuzz targets for the same parsers are in fuzz/; see
fuzz/README.md. CI runs each of them for a minute.
License
Apache License 2.0; see LICENSE.