BGPSec Considerations for AS Migration

There is a common method of managing an ASN migration using some BGP knobs that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. In order to ensure that this behavior is understood and considered for future modifications to the BGP4 protocol specification, especially as it concerns the handling of AS_PATH attributes, the behavior and process has been defined in draft-ga-idr-as-migration. Accordingly, it is necessary to discuss this de facto standard to ensure that the process and features are properly supported in BGPSec , because it is explicitly designed to protect against changes in the BGP AS_PATH, whether by choice, by misconfiguration, or by malicious intent. It is critical that the BGPSec protocol framework is able to support this operationally necessary tool without creating an unacceptable security risk or exploit in the process.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The use case being discussed in draft-ga-idr-as-migration is as follows: For whatever the reason, a provider is in the process of merging two or more ASNs, where eventually one subsumes the other(s). Confederations RFC 5065 are *not* being implemented between the ASNs, but vendor-specific configuration knobs are being used to masquerade as the old ASN for the PE-CE eBGP session, or to manipulate the AS_PATH, or both. While BGPSec does have a case to handle standard confederation implementations, it may not be applicable in this exact case. The reason that this may drive a slightly different solution in BGPSec than a standard confederation is that unlike in a confederation, eBGP peers may not be peering with the "correct" external ASN, and the forward-signed updates are for a public ASN, rather than a private one, so there is no expectation that the BGP speaker should strip the updates before propagating the route to its eBGP neighbors. In the following examples, AS200 is being subsumed by AS300, and both ASNs represent an SP network. AS100 and 400 represent end customer networks.

Since the methods and implementation discussed in draft-ga-idr-as-migration are not technically a part of the BGP4 protocol implementation, but rather a vendor-specific optimization, BGPSec is not technically required to ensure that it continues functioning as it does today. However, this is widely used during network integrations resulting from mergers and acquisitions, as well as network redesigns, and therefore it is not feasible to simply eliminate this capability on any BGPSec-enabled routers/ASNs. What follows is a discussion of the potential issues to be considered regarding how ASN-migration and RPKI validation might interact. Additionally, companies rarely stop with one merger/acquisition/divestiture, and end up accumulating several legacy ASNs over time. Since they are using methods to migrate that do not require coordination with customers, they do not have a great deal of control over the length of the transition period as they might with something completely under their administrative control like a key roll. This leaves many SPs with multiple legacy ASNs which don't go completely and cleanly away very quickly, if at all. As solutions are being proposed for RPKI implementations to solve this transition case, operational complexity and hardware scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network have to be carefully considered. While part of the recommendation may be "SPs SHOULD NOT remain in this transition phase indefinitely because of the operational complexity and scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network", this is of limited utility as a solution, and so every effort needs to be made to allow the transition period to be less onerous, on the assumption that it will likely be protracted.

In the scenario discussed, AS200 is being replaced by AS300. If there are any existing routes originated by AS200 on the router being moved into the new ASN, this is likely as simple as generating new ROAs for the routes with the new ASN and treating them as new routes to be added to AS300/removed from AS200. However, consider the situation where one or more PEs are still in AS200, and are originating one or more routes. When those routes arrive at PE1, which is now a part of AS300 and instructed to use replace-as to remove AS200 from the path, how does it handle routes originated from AS200? If the route now shows up as originating from AS300, any downstream peers' validation check will fail unless a ROA is *also* available for AS300 as the origin ASN, meaning that there will be overlapping ROAs until all routers originating prefixes from AS200 are migrated to AS300. [AUTHOR's NOTE, remove before publishing: may need a citation to the specific text in the Origin validation spec RFC 6480 or related documents that allows an overlap period on ROAs for transitions like this. also may need to rewrite this as a procedure in RFC2119 language, rather than a discussion. END NOTE]

BGPSec Path Validation requires that each router in the AS_PATH cryptographically sign its update to assert that "Every AS listed in the AS_PATH attribute of the update explicitly authorized the advertisement of the route to the subsequent AS in the AS_PATH." Since this migration technique is explicitly modifying the AS_PATH between two eBGP peers who are not coordinating with one another (are not in the same administrative domain), no level of trust can be assumed, and therefore it may be difficult to identify legitimate manipulation of the AS_PATH for migration activities when compared to manipulation due to misconfiguration or malicious intent.

When PE1 is moved from AS200 to AS300, it will be provisioned with the appropriate keys for AS300 so that it can begin forward-signing routes using AS300. However, there is currently no guidance in the BGPSec protocol specification on whether or not the forward-signed ASN value MUST match the configured "remote-as" to validate properly. That is, if CE1's BGP session is configured as "remote-as 200", the presence of "local-as 200" on PE1 will ensure that there is no ASN mismatch on the BGP session itself, but if CE1 receives updates from its remote neighbor (PE1) forward-signed from AS300, should the BGPSec validator on CE1 still consider those valid by default? If it does, is there any potential attack vector to consider? If enabling strict validation that remote-AS and forward-signed-AS match is desirable, a possible alternative would be to retain the keys for AS200 on PE1, and forward-sign towards CE1 with AS200 and Pcount=0. However, this would mean passing a pcount=0 between two ASNs that are in different administrative and trust domains such that it could represent a significant attack vector to manipulate BGPSec-signed paths. The expectation for legitimate instances of Pcount=0 (to make a route-server that is not part of the transit path invisible) is that there is some sort of existing trust relationship between the operators of the route-server and the downstream peers such that the peers could be explicitly configured by policy to permit PCount=0 announcements only on the sessions where they are expected, and otherwise reject them. For the same reason that things like local-as are used for ASN migration without end customer coordination, it is unrealistic to assume any sort of coordination between the SP and the administrators of CE1 to ensure that they will by policy accept PCount=0 signatures during the transition period, and therefore this may not be a workable solution.

Inbound is more complicated, because the CE doesn't know that PE1 has changed ASNs, so it is forward-signing all of its routes with AS200, not AS300. The BGPSec speaker cannot [MUST NOT??] manipulate previous signatures, and therefore cannot manipulate the previous AS_Path without causing a mismatch that will invalidate the route. If the updates are simply left intact, the ISP would still need to publish and maintain valid and active public-keys for AS 200 if it is to appear in the BGPSec_Path_Signature in order that receivers can validate the BGPSEC_Path_Signature arrived intact/whole. However, if the updates are left intact, this will cause the AS_PATH length to be increased, which as previously stated is undesirable. More discussion is needed to determine possible solutions that enable this transition without defeating the added security that BGPSec provides.

PLACEHOLDER for a set of requirements, defining what SIDR Origin Validation/BGPSEC <RFC2119-word> do to enable this migration strategy to work securely. Need input from WG as to how to proceed. Options: Add implementation considerations and/or protocol changes to support AS-Migration into the BGPSec protocol doc or another existing BGPSec document Use this draft to document how BGPSec and Origin Validation will need to handle the AS-migration procedure (move to PS status?), possibly as an update to the BGPSec protocol document Explicitly prohibit/deprecate this process for AS-Migration (a la AS_Sets) as something that cannot be properly secured within BGPSec define a new/updated/improved standard method for asymmetric ASN migrations which is explicitly designed to operate within the bounds of BGPSec (instead of trying to make the existing implementations work with no changes) - probably in IDR The author does not believe that option #3 is the correct course of action because this is in wide use among operators today, and no acceptable alternative exists to make the act of merging ASNs less onerous.

Thanks to Kotikalapudi Sriram and Shane Amante for their comments.

This memo includes no request to IANA.

This draft discusses a process by which one ASN is migrated into and subsumed by another. Because this involves manipulating the AS_Path to make it deviate from the actual path that it took through the network, it is in some ways attempting to do exactly what BGPSec is working to prevent. The BGPSec implementation MUST be able to manage this legitimate use of AS_Path manipulation without generating a vulnerability in the RPKI route security infrastructure that can be exploited by a malicious actor.