Where RPKI, BGPsec and the transport disagree¶

Attack pattern¶

RPKI validates who may originate a prefix. BGPsec validates who relayed it. They are separate mechanisms with separate caches, separate refresh intervals and separate ideas of what an unknown state means, which leaves a route free to pass one and fail the other. What happens next is local policy rather than protocol. Most of the openings between them are timing: a revocation that has reached one cache and not yet the other, validity periods expiring on different clocks, validation runs on different schedules. Underneath both sit dependencies nobody files under routing security. Trust anchors are retrieved by name, so DNS resolution sits beneath a control designed to fix a routing trust problem. Signature validity is judged against a clock, and the clock is usually set by NTP.

1. Cross-Protocol Attack Vectors [OR]

    1.1 RPKI-BGPsec Integration Attacks [OR]

        1.1.1 Validation Conflict Exploitation [OR]
            1.1.1.1 RPKI-valid but BGPsec-invalid route injection
            1.1.1.2 BGPsec-valid but RPKI-invalid path propagation
            1.1.1.3 Unknown state handling discrepancies

        1.1.2 Timing Attack Coordination [OR]
            1.1.2.1 Different cache TTL exploitation
            1.1.2.2 Revocation propagation timing gaps
            1.1.2.3 Validation frequency mismatches

        1.1.3 Trust Chain Collisions [OR]
            1.1.3.1 Shared CA compromise effects
            1.1.3.2 Different crypto algorithm support
            1.1.3.3 Protocol version compatibility issues

    1.2 TLS-BGPsec Attack Chains [OR]

        1.2.1 Certificate Trust Exploitation [OR]
            1.2.1.1 Validation policy conflict exploitation

        1.2.2 Session Handling Attacks [OR]
            1.2.2.1 Cross-protocol side-channel attacks

        1.2.3 Implementation Shared Code [OR]
            1.2.3.1 Common crypto library vulnerabilities
            1.2.3.2 Shared memory safety issues
            1.2.3.3 Cross-protocol resource exhaustion

    1.3 Network Layer Integration Attacks [OR]

        1.3.1 IP Layer Exploitation [OR]
            1.3.1.1 Fragmentation attacks affecting BGPsec
            1.3.1.2 TTL-based attacks on validation
            1.3.1.3 DSCP priority manipulation

        1.3.2 Transport Layer Attacks [OR]
            1.3.2.1 TCP session manipulation affecting BGPsec
            1.3.2.2 QUIC protocol interaction issues
            1.3.2.3 UDP-based amplification attacks

        1.3.3 Application Layer Integration [OR]
            1.3.3.1 HTTP-based validator API attacks
            1.3.3.2 DNS dependencies for trust anchor resolution
            1.3.3.3 NTP timing attacks on signature validation

Two validators, one route¶

Origin validation and path validation answer different questions. A route can satisfy one and fail the other, and the result is a policy choice rather than a protocol outcome.
The two run separate caches on separate refresh intervals, so there is always a period in which they disagree about what has been revoked.
Unknown is not invalid. Wherever that state is handled differently between the two, the difference is the opening.
Trust anchor retrieval resolves a name, which puts a DNS problem underneath a control built to fix a routing trust problem.
Signature validity is judged against a clock that NTP usually sets, and NTP has a trust story of its own.
Shared cryptographic libraries carry shared flaws, so a weakness found while attacking TLS arrives in the routing stack with nobody having attacked routing.