Partial deployment and the people running it¶

Attack pattern¶

The protocol works. Almost nobody runs it. BGPsec is negotiated as a BGP capability, so a session with a peer that does not offer it proceeds unsigned, by specification rather than by defect. In a routing system where path validation deployment remains negligible, every non-participating neighbour is a legitimate route around the signature, and a path crossing one arrives without a complete chain with nobody at fault. Partial deployment is not a transitional inconvenience to be waited out; for the foreseeable future it is the operating condition, which is why the risk table prices this branch low. It asks for nothing clever. Beside it runs the ordinary human surface: an operator credential, a policy configured once, and the confidence that follows from having deployed something.

1. Exploit Operational Weaknesses [OR]

    1.1 Partial Deployment Exploitation [OR]

        1.1.1 Validation Gap Attacks [OR]
            1.1.1.1 Route leaks through non-BGPsec ASes
            1.1.1.2 Mixed validation policy exploitation
            1.1.1.3 Border router misconfiguration

        1.1.2 Policy Inconsistency [OR]
            1.1.2.1 Differing local validation policies
            1.1.2.2 Conflict between RPKI and BGPsec validation
            1.1.2.3 Graceful restart compatibility issues

        1.1.3 Transition Period Attacks [OR]
            1.1.3.1 Exploitation during protocol migration
            1.1.3.2 Backward compatibility weaknesses
            1.1.3.3 Dual-stack (IPv4/IPv6) implementation gaps

    1.2 Human Factor Exploitation [OR]

        1.2.1 Social Engineering [OR]
            1.2.1.1 Operator credential theft
            1.2.1.2 Fake security alert social engineering
            1.2.1.3 Supply chain impersonation attacks

        1.2.2 Configuration Errors [OR]
            1.2.2.1 Weak signature policy configuration
            1.2.2.2 Incorrect trust anchor deployment
            1.2.2.3 Key management policy mistakes

        1.2.3 Monitoring Gaps [OR]
            1.2.3.1 Delayed attack detection
            1.2.3.2 False sense of security from partial deployment
            1.2.3.3 Lack of BGPsec-specific monitoring

    1.3 Economic and Coordination Attacks [OR]

        1.3.1 Resource Asymmetry Exploitation [OR]
            1.3.1.1 CPU-intensive signature attacks on smaller ASes
            1.3.1.2 Storage exhaustion through key history attacks
            1.3.1.3 Bandwidth consumption via BGPsec update floods

        1.3.2 Governance Attacks [OR]
            1.3.2.1 Policy registry manipulation
            1.3.2.2 Standards body influence operations
            1.3.2.3 Certification authority lobbying

        1.3.3 Timing and Persistence [OR]
            1.3.3.1 Long-term key compromise persistence
            1.3.3.2 Attack synchronisation across multiple ASes
            1.3.3.3 Holiday/weekend attack timing

Nobody has to break it while nobody runs it¶

BGPsec is a negotiated capability. A peer that does not offer it gets an unsigned session, which is the specification behaving correctly.
Path validation deployment stays negligible where origin validation has real coverage. The two are spoken of together and protect different things.
A route crossing a single non-participating autonomous system arrives without a complete signature chain, and no participant has misbehaved.
What to do with an unverifiable path is local policy, and policies differ. The most permissive neighbour is the one that decides.
Verification cost falls on the receiver, one signature per hop, which lands hardest on the smallest networks and gives a flood its leverage.
Partial deployment produces confidence out of proportion to coverage. The tree files that under monitoring gaps, and it is probably the most durable item on the branch.