BGPsec Considerations for Autonomous System (AS) Migration
updates
- rfc-8205 — BGPsec Protocol Specification
Extracted elements (23)
Double-signing is applied only per-session at the PE router with AS-migration sessions, not network-wide, because applying AS-hiding across all routes between the two ASNs could result in routing loops and other undesirable behavior.
The solution minimizes additional complexity during the transition period on the assumption that AS migration transitions are often protracted, since SPs cannot force simultaneous cutover of customers and thus accumulate multiple legacy ASNs for extended periods.
Using pCount=0 directly between the PE and CE (different administrative domains) was rejected because it would represent a significant attack vector — legitimate pCount=0 use requires an explicit trust relationship and policy configuration between peers, which cannot be assumed for migrating SPs and their customers.
BGPsec confederations support in RFC 8205 is not directly applicable to AS migration because in migration, eBGP peers may not be peering with the correct external ASN and forward-signed updates are for public ASNs, so signatures are not stripped before propagation as they would be in a confederation.
RFC 8205 does not specify whether the forward-signed ASN value must match the configured remote AS for BGPsec validation; CE1 configured as 'remote AS 64510' may or may not accept updates forward-signed from AS64500, and this cannot be assumed to work across vendor implementations.
When reconstructing AS_PATH for non-BGPsec neighbors from the Secure_Path, pCount=0 ASNs do not appear in the reconstructed AS_PATH at all (per RFC 8205 Section 4.4), maintaining correct path length behavior for legacy peers.
Any BGPsec-capable route-reflectors in the path of migration-related updates MUST reflect them transparently to their BGPsec-capable clients.
BGPsec-capable routers that receive updates from BGPsec-enabled iBGP neighbors MUST accept updates with new (properly formed) BGPsec attributes, including the presence of pCount=0 on a previous signature.
BGPsec MUST NOT lengthen the AS path during migration.
BGPsec MUST NOT require any reconfiguration on the remote eBGP neighbor (CE) to support AS migration.
BGPsec MUST operate within existing trust boundaries and cannot expect remote side to accept pCount=0 from untrusted or non-confederation neighbors.
BGPsec MUST support AS migration for both inbound and outbound route announcements without reducing BGPsec's protections for route path.
BGPsec SHOULD NOT require global (network-wide) configuration changes to support migration; required configuration changes should be limited to the PE devices being migrated.
For each ROA that authorizes the old ASN to originate a prefix, a new ROA MUST also be created that authorizes the replacing ASN to originate the same prefix.
For inbound announcements (CE to PE), the PE router MUST generate a signature from the old (local) ASN forward-signing to the new (global) ASN with pCount=0; signing in iBGP is required for this AS-migration scenario only.
For outbound announcements (PE to CE), the PE router MUST generate a valid BGPsec signature for both configured ASNs: a signature from the new (global) ASN forward-signing to the old (local) ASN with pCount=0, and then a forward signature from the old (local) ASN to the target eBGP ASN with pCount=1.
In iBGP migration scenarios, the router being migrated MUST sign updates from the old ASN to the new ASN with pCount=0 before sending them on to other peers.
The PE router MUST be provisioned with valid keys for both configured ASNs (old and new), and the key for the old ASN MUST be kept valid until all eBGP sessions are migrated to the new ASN.
Origin Validation during AS migration requires creating new ROAs for the replacing ASN for all prefixes authorized under the old ASN, since AS replacement changes the origin AS visible to downstream peers. Multiple ROAs authorizing different ASNs for the same prefix are permissible per RFC 6480.
The double-signing technique: each routing update exchanged with an eBGP neighbor still using the old ASN is signed twice — once with the ASN to be hidden (pCount=0) and once with the ASN that will remain visible (pCount=1). This simulates an internal BGP hop between the two ASNs without requiring an actual eBGP session.
The Secure_Path attribute (defined in RFC 8205) is used instead of AS_PATH between BGPsec peers. pCount=0 entries are present in Secure_Path but omitted when reconstructing AS_PATH for non-BGPsec neighbors.
If the AS's keys are compromised or zero-length keys are permitted during migration, an AS_PATH shortening attack is possible, but these are existing security risks for BGPsec and not new vulnerabilities introduced by the migration procedure.
The AS migration process intentionally manipulates AS_PATH in exactly the manner BGPsec is designed to prevent; BGPsec must manage this legitimate use without creating a vulnerability in RPKI route security infrastructure. The double-signing solution is considered reasonably secure because it requires both signatures to be secured as if forward-signed between two eBGP neighbors, requiring the router to hold valid keys for both ASNs.