Trust anchors, validators and peer sessions¶

Attack pattern¶

BGPsec answers the question of whose signature counts with a certificate chain rooted in the RPKI, and the RPKI answers it with a Trust Anchor Locator: a short file naming a public key and a URL to fetch the rest from. Five of them, one per regional registry, retrieved over the network on a schedule by software most operators installed from a package mirror. The whole trust decision therefore sits behind a file, a fetch and a build pipeline. Below that sits the validator, which is ordinary software parsing untrusted repository data at scale and feeding a router over RTR, a router that does not re-derive the conclusion it is handed. Below that again is the BGP session itself, still carried over TCP and protected by TCP-AO wherever somebody configured it and by MD5 wherever they did not.

1. Attack BGPsec Infrastructure [OR]

    1.1 Trust Anchor Compromise [OR]

        1.1.1 Trust Distribution Attacks [OR]
            1.1.1.1 Malicious TAL (Trust Anchor Locator) distribution
            1.1.1.2 Package mirror compromise for validator software
            1.1.1.3 DNS poisoning for trust anchor retrieval

        1.1.2 Anchor Maintenance Exploits [OR]
            1.1.2.1 Delayed anchor revocation propagation
            1.1.2.2 Weak anchor rotation procedures
            1.1.2.3 Historical anchor abuse

        1.1.3 Cross-Protocol Trust Collisions [OR]
            1.1.3.1 RPKI-BGPsec trust chain conflicts
            1.1.3.2 Shared HSM compromise across protocols

    1.2 Validator Infrastructure Attacks [OR]

        1.2.1 Software Vulnerabilities [OR]
            1.2.1.1 Memory safety issues in validators (Rust/C++)
            1.2.1.2 Logic flaws in path validation
            1.2.1.3 Denial-of-service through resource exhaustion

        1.2.2 Cache Poisoning [OR]
            1.2.2.1 Stale data attacks during sync intervals
            1.2.2.2 MITM attacks on validator-to-repository communication
            1.2.2.3 Repository compromise with malicious data

        1.2.3 Configuration Manipulation [OR]
            1.2.3.1 Admin interface compromises
            1.2.3.2 Misconfigured trust boundaries
            1.2.3.3 Weak access controls on validator systems

    1.3 Network Infrastructure Targeting [OR]

        1.3.1 Routing Table Poisoning [OR]
            1.3.1.1 Injection of malicious BGPsec paths
            1.3.1.2 Withdrawal of valid BGPsec routes
            1.3.1.3 Route flap attacks with signed updates

        1.3.2 Peer Session Compromise [OR]
            1.3.2.1 TCP-AO/MD5 bypass for BGP sessions
            1.3.2.2 Session reset attacks during key rotation
            1.3.2.3 MITM on BGPsec peer connections

        1.3.3 Resource Exhaustion [OR]
            1.3.3.1 CPU exhaustion through complex signature validation
            1.3.3.2 Memory exhaustion via large BGPsec updates
            1.3.3.3 Storage exhaustion from key history retention

A short file and a scheduled fetch¶

A Trust Anchor Locator is a public key and a URL. Whoever controls the fetch decides what the validator believes from that point on.
Validators are ordinary software parsing untrusted repository data at volume, which is the standard shape for both memory safety flaws and resource exhaustion.
Synchronisation is periodic, so a validator’s view is stale for part of every interval, including its view of what has been revoked.
Revocation travels at the speed of the slowest fetch. A withdrawn certificate stays good for anyone still serving the previous cache.
The router accepts the validator’s verdict over RTR without re-deriving it, so compromising the validator is equivalent to compromising every decision downstream of it.
Under the cryptography the session is still TCP. TCP-AO protects it where it was configured, and MD5 where nobody revisited the decision.