# BGPsec and PQC: Routing Security Long-Term **Source**: https://quantumsequrity.com/blog/bgpsec-pqc **Category**: Network Protocols --- [← Back to Blog](../../blog.html) Network Protocols # BGPsec and PQC: Routing Security Long-Term 11 min read BGP (Border Gateway Protocol) is what makes the internet work as a unified network. When you visit a website hosted in Tokyo from a laptop in São Paulo, BGP is the protocol that figured out the path the packets should take across dozens of autonomous systems (ASes) operated by independent network operators. It is, in many ways, the most consequential protocol on the internet, and it is famously fragile — a single misconfiguration in one network operator's router can route huge fractions of the world's traffic to the wrong place. BGPsec is the cryptographic extension that adds path verification to BGP. Defined in RFC 8205 in September 2017, BGPsec lets a router verify that the AS path attribute attached to a BGP route announcement is actually authentic — that each AS in the path has genuinely participated in the announcement, rather than just appearing in the path because some malicious or misconfigured router said so. BGPsec is built on ECDSA signatures attached to path attributes. Migrating those signatures to post-quantum cryptography is a thorny problem because BGP is already operating on the edge of message size limits, and PQC signatures are dramatically larger than ECDSA. This blog post walks through how BGPsec works, why PQC is hard for it, and what the long-term picture looks like. ## BGP And BGPsec In Two Paragraphs BGP is defined in RFC 4271. When network operator A announces "I can reach prefix 192.0.2.0/24", that announcement propagates from A's routers to its peers, then to its peers' peers, and so on across the global routing system. The AS_PATH attribute records each AS that the announcement has traversed. Without BGPsec, a malicious operator can announce a prefix it doesn't own (BGP hijacking), or claim a more direct path than it actually has (BGP path manipulation), and the lie propagates because nothing cryptographically authenticates the path. BGPsec adds that authentication. Each AS that propagates a route signs the BGP UPDATE message with its private key. The signatures are attached as path attributes. A receiving router can verify each signature using the corresponding public key, which is published in the Resource Public Key Infrastructure (RPKI). If any signature fails, the route is rejected. ## Why BGP Was Vulnerable Before BGPsec Famous BGP incidents include the Pakistan Telecom YouTube hijack of 2008 (Pakistan accidentally announced a route to YouTube's prefixes that propagated globally and took YouTube down for hours), the Indosat hijack of 2014 (a major Asian ISP briefly advertised paths to thousands of unrelated prefixes), and the Rostelecom incidents (a Russian ISP repeatedly hijacked traffic for short periods). These were not all malicious. Some were misconfigurations. But they showed that without cryptographic verification, the global routing system was vulnerable to errors and attacks alike. BGPsec was the IETF response. By signing path attributes, an attacker who lacks the private key for an AS cannot forge that AS's participation in a path. The signatures provide cryptographic proof of who said what. ## ECDSA Signatures In BGP UPDATE Messages BGPsec signatures are ECDSA over the curve P-256 with SHA-256, producing 64-byte signatures. Each AS that propagates a route adds one signature. So a route that has traversed 10 ASes carries 10 signatures, totaling 640 bytes plus overhead. BGP UPDATE messages have a maximum size of 4,096 bytes per RFC 4271 (with extensions to 65,535 bytes via RFC 8654). For typical paths of 5-10 ASes, ECDSA signatures fit comfortably. ## Why PQC Is Brutal For BGPsec Now substitute ML-DSA-65 signatures, at 3,309 bytes each. A path of 10 ASes would carry 33,090 bytes of signatures alone. That is an order of magnitude larger than the current BGPsec messages. The 4,096-byte default BGP UPDATE limit is shattered. Even the 65,535-byte extended limit is stressed. In practice, BGP control plane traffic with PQC signatures would be 30-50x larger than today's. The implications cascade: - **Routers' control-plane CPU**: BGP message parsing and signature verification load increases dramatically. A modern core router processes BGP updates at high rates; PQC verification is several times slower than ECDSA verification, and the bigger messages are more expensive to copy and parse. - **TCP buffers**: BGP runs over TCP. Larger messages mean larger buffers per session. Routers have many BGP sessions; the memory footprint grows. - **Convergence time**: When the routing system converges after a topology change, every relevant route is re-announced. Bigger messages mean slower convergence, which means longer windows where traffic is misrouted or blackholed. - **Storage**: Routers cache BGP routes. Bigger routes mean more memory to hold the same routing table. For perspective: the current full IPv4 BGP routing table has roughly 950,000 prefixes. Multiply by tens of signatures per prefix in a PQC future, and the storage and verification load is enormous. ## Sphincs/SLH-DSA Is Worse If ML-DSA is bad for BGPsec, SLH-DSA is catastrophic. SLH-DSA-128s signatures are 7,856 bytes; SLH-DSA-256f is 49,856 bytes. A 10-hop path with SLH-DSA-256f would carry half a megabyte of signatures. SLH-DSA is not a realistic option for BGPsec. The size is operationally impossible. ## Falcon: The Maybe-Hope Falcon (FIPS 206, in development) produces signatures of around 666 bytes for Falcon-512 and 1,280 bytes for Falcon-1024. These are larger than ECDSA's 64 bytes but small enough that BGPsec could survive. A 10-hop path with Falcon-512 signatures would be 6,660 bytes — manageable in BGP's extended message limits. Falcon-1024 would be 12,800 bytes — workable. The catch with Falcon is implementation. Falcon's signing algorithm uses constant-time floating-point arithmetic, which is notoriously hard to get right. Side-channel attacks have been published against early Falcon implementations. The FIPS 206 standard is still in development, partly because the standardization process is being careful about implementation guidance. For BGPsec specifically, Falcon-512 might be the only PQC signature scheme that fits the operational constraints. The IETF is watching FIPS 206 closely. ## Stateful Hash Signatures: LMS And HSS LMS and HSS (RFC 8554) are stateful hash-based signature schemes. LMS signatures range from about 1,000 bytes to several KB depending on parameters. They are relatively compact and based on the well-understood security of hash functions. The catch with stateful signatures is the state itself. Each signing key has a fixed supply of one-time signatures, and reusing an index breaks security entirely. For BGP, where routers continuously sign updates, state management is hard. A router that crashes and restarts must somehow recover its signature counter without reusing indices. For BGPsec, LMS could work if state is managed carefully. The IETF has explored this as a possibility but no consensus exists. ## SIDR Operations: The IETF Working Group The IETF working group that maintains BGPsec is SIDROPS (Secure Inter-Domain Routing Operations). They have begun preliminary discussion of PQC migration but have not adopted a specific draft yet. The current consensus seems to be: wait. ECDSA-P256 in BGPsec is not under any near-term threat. Quantum computers capable of breaking ECDSA-P256 are not on the immediate horizon. PQC signature schemes are still maturing. Any premature commitment to a PQC algorithm could be costly to undo. The working group is in monitoring mode. They expect to revisit PQC for BGPsec when: - FIPS 206 (Falcon) is finalized and has stable implementations. - Major router vendors (Cisco, Juniper, Arista, Nokia) have implemented PQC primitives in their fast paths. - There is operational experience with ML-DSA in similar PKI contexts (X.509 certificates, RPKI). ## RPKI's Role In The PQC Story BGPsec depends on RPKI to publish the public keys of each AS. RPKI is a separate (and more widely deployed) system that we cover in our [RPKI PQC article](../../blog/rpki-pqc.html). The PQC migration of BGPsec is closely tied to RPKI's migration: BGPsec cannot move to ML-DSA signatures unless RPKI can publish ML-DSA keys. Today, RPKI uses ECDSA. Migrating RPKI to PQC is itself a multi-year project. BGPsec's PQC migration is gated on RPKI's. ## Adoption Status: BGPsec Is Barely Deployed A blunt fact about BGPsec: deployment is very limited. Major network operators have largely stuck with simpler RPKI-based mechanisms (ROA validation, which checks origin AS but not full path) rather than full BGPsec. The complexity of BGPsec, the cryptographic overhead even with ECDSA, and the need for every AS in a path to participate have made BGPsec a niche technology. This means PQC for BGPsec is somewhat academic. The protocol exists and is specified, but very few networks actually use it. If BGPsec eventually gains broader adoption, PQC migration becomes urgent. If BGPsec remains a niche, PQC migration is less pressing. The IETF is investing in alternative path-validation mechanisms (like ASPA, Autonomous System Provider Authorization, RFC 8210bis) that achieve some of BGPsec's goals with simpler cryptography. ASPA might gain wider adoption than BGPsec ever did, and ASPA's PQC migration would then become the more important question. ## Compression And Encoding Considerations One mitigation considered for PQC BGPsec is signature compression. ML-DSA signatures contain some structured data that compresses non-trivially with general-purpose compression. However, the deterministic-output requirement of BGP makes compression awkward — every router needs to deterministically produce the exact bytes that get signed. A more promising direction is signature aggregation. If multiple ASes in a path could share signature data through a tree structure or batched verification, the per-AS overhead might shrink. This is research territory, not standardized work. The IETF has not committed to either compression or aggregation. The current direction seems to be: wait for Falcon (FIPS 206) and use its smaller signatures directly, rather than trying to compress ML-DSA signatures. ## Operational Reality: Why BGPsec Stalled A frank observation about BGPsec: even with classical ECDSA signatures, BGPsec deployment never reached scale. The complexity of the protocol, the requirement for every AS in a path to participate, and the operational risk of misconfiguration outweighed the security benefit for most operators. RPKI ROA validation, which provides origin verification without path verification, became the pragmatic choice. This affects PQC migration timelines. If BGPsec remains a niche technology, PQC for BGPsec is a relatively academic concern. If a future incident or regulatory requirement pushes broader BGPsec adoption, PQC migration becomes urgent overnight. The IETF's deliberate pace on BGPsec PQC reflects this uncertainty. The working group does not want to commit to an algorithm that might be inadequate (too large, too slow) when deployment finally happens. ## What QNSQY Recommends For network operators today: 1. **Deploy RPKI ROAs.** This is the basic origin-validation hygiene that everyone should have, and is independent of BGPsec or PQC. 2. **Don't deploy BGPsec yet, unless you have specific reason to.** The operational complexity is significant and the deployment ecosystem is sparse. 3. **Watch the SIDROPS working group.** When PQC BGPsec drafts mature, plan accordingly. 4. **Consider ASPA.** If your concern is path validation rather than just origin validation, ASPA may be a more practical mechanism than BGPsec. For QNSQY itself, we have no direct dependency on BGPsec. Our infrastructure relies on standard BGP plus our cloud providers' RPKI deployments. PQC at the BGP layer is something we will inherit when it eventually rolls out, with no action on our part. ## Frequently Asked Questions **Q: Is BGP itself going to need PQC?** BGP without BGPsec uses no asymmetric cryptography on its messages — it relies on TCP MD5 (RFC 2385) or TCP-AO (RFC 5925) for session integrity. Those use symmetric keys, which Grover's algorithm only halves the security of. So plain BGP is mostly fine. **Q: Are there real-world BGPsec deployments to worry about?** Very few. Most internet operators use RPKI ROA validation (which doesn't use BGPsec) and rely on operational discipline for path correctness. **Q: Could quantum computers attack BGP today?** Not in any meaningful sense. The cryptographic surface is small, and the actual attacks against BGP today are operational (misconfigurations, policy errors) rather than cryptographic. **Q: When will BGPsec PQC actually matter?** When BGPsec deployment becomes meaningful and quantum capability becomes credible. Today, neither is true. Realistic timeline: 2030s. **Q: What about IPsec for BGP sessions?** Some operators wrap BGP sessions in IPsec for transport security. The PQC story for [IPsec is mature](../../blog/ipsec-pqc-ikev2.html) and that protects the BGP session itself. But it doesn't protect path attributes the way BGPsec does — a BGP peer could still announce malicious paths, and IPsec wouldn't notice. ## Sources 1. RFC 8205 — BGPsec Protocol Specification. https://datatracker.ietf.org/doc/html/rfc8205 2. RFC 4271 — A Border Gateway Protocol 4 (BGP-4). https://datatracker.ietf.org/doc/html/rfc4271 3. RFC 8654 — Extended Message Support for BGP. https://datatracker.ietf.org/doc/html/rfc8654 4. RFC 8554 — Leighton-Micali Hash-Based Signatures. https://datatracker.ietf.org/doc/html/rfc8554 5. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final 6. IETF SIDROPS Working Group. https://datatracker.ietf.org/wg/sidrops/ ## Related Articles - [RPKI PQC](../../blog/rpki-pqc.html) - [What Is Post-Quantum Cryptography?](../../blog/what-is-post-quantum-cryptography.html) - [ML-DSA vs SLH-DSA](../../blog/mldsa-vs-slhdsa.html) - [NIST FIPS Guide](../../blog/nist-fips-guide.html) - [IPsec IKEv2 PQC](../../blog/ipsec-pqc-ikev2.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)