ASPA-based AS_PATH Verification for BGP Export

3.1. Partial ASPA ingress and BGP Roles deployment

ASPA and BGP Roles may be deployed incrementally inside a network. In large networks, it is common for ASBRs to be upgraded in stages, for older routers to remain in service for some time, or for different border routers to support different sets of features. As a result, an ingress ASBR may be unable to perform ASPA-based AS_PATH verification or to attach the intended BGP Role or OTC-derived intra-AS signal, while an egress ASBR or a detached verification system may already have the necessary capability.¶

In such partial-deployment environments, egress verification can provide additional coverage for routes that would otherwise leave the AS without ASPA-based export checks. This is especially useful when full-table routes received at an unupgraded ingress router are later propagated toward customer-facing, peer-facing, or provider-facing egress points that do support ASPA validation.¶

Egress verification in this scenario is a staged-deployment aid and a local assurance mechanism. It does not replace BGP Roles, OTC, or an equivalent intra-AS leak-prevention signal when such marking is available. Instead, it allows an operator to gain useful verification coverage before all ingress ASBRs have been upgraded, and to detect export-side problems closer to the point where routes leave the AS.¶

3.2. Missing Provider in ASPA record

When a network (AS N) fails to publish a complete ASPA record and omits a certain provider (AS P), all routes sent through this BGP session become invalid when their AS_PATHs are checked later by a peer (AS Q) or provider (AS Y) of AS P, or any other AS later on the path.¶

Let's assume that AS N is otherwise configured well and announces only its own routes and its customers' routes to its providers. Also, all customers of N have either well configured ASPA or no ASPA at all. Then, all routes announced to AS P by AS N have AS_PATH which begins with AS N and possibly continues with other AS numbers. Such an AS_PATH is evaluated as ASPA Valid or Unknown by the Upstream algorithm as specified in [I-D.ietf-sidrops-aspa-verification], section 5.4, based on the published customers' ASPA.¶

AS P then redistributes these routes to its providers (AS Y) and peers (AS Q). On egress eBGP, AS P is prepended to AS_PATH as specified in [RFC4271], section 5.1.2. In turn, this path is evaluated at AS Y and AS Q by the Upstream algorithm again, but as P is NotProvider+ of N, all the routes suddenly appear ASPA Invalid.¶

In the early adoption days, this scenario may happen even farther from the mistaken network, possibly leading to mysterious misrouting. It is also possible that the mistakenly omitted network is a backup provider, and the invalid routes get propagated only in case of a primary link failure, which may act as an additional deterrent for early ASPA adoption.¶

      +-----------------+
      |      AS Y       |
      +-----------------+
              |
      +---------------+      +-------------+
      |      AS P     |------|     AS Q    |
      | Providers: Y  |      |  Peer of P  |
      +---------------+      +-------------+
              |
      +---------------------+
      |          AS N       |
      | Providers missing P |
      +---------------------+

3.3. Network merging and splitting

When a single entity controls multiple autonomous systems, they may decide to merge them, or in reverse, they may decide to split one AS to multiple AS's, or they simply decide to renumber their AS. This process almost never happens atomically, and while there are multiple approaches, almost always there are transitional periods when a single AS uses multiple AS numbers.¶

These cases include situations when one BGP speaker receives a route via eBGP, acting as AS M, but that route is then sent over e.g. confederated eBGP to another BGP speaker which announces the route via eBGP, acting as a different AS N. Generally, all mentioned problems should be mitigated by first extending all ASPA records by the new AS number, and removing the old one only after it's been disused, but ASPA-based AS_PATH verification on BGP egress ensures that all needed ASPA records have indeed been updated accordingly.¶

3.4. Advanced AS_PATH Manipulation

There are various common AS_PATH manipulation techniques. The most common one is AS_PATH Stuffing where the local AS number is prepended multiple times before exporting to a neighboring network, so that the resulting route is depreferenced, and possibly used as a backup link should the main link fail.¶

If the network operator happens to make a typo in their own AS number [bgp-typo] or any other configuration mistake involving their AS_PATH manipulation, they may accidentally introduce a path invalidity. Running ASPA-based AS_PATH verification on BGP egress catches these mistakes early on, possibly before actually propagating the route.¶

These cases generally include scenarios when a neighboring network thinks that their neighbor is AS M, while their routes are later announced with AS N prepended instead. In such scenarios, if the neighboring network includes only AS M as their provider, the route becomes invalid later on in a similar way as described in the previous section.¶

4.1. Basic Egress Verification

Any BGP speaker advertising routes to other autonomous systems via eBGP (egress) SHOULD run ASPA-based AS_PATH Verification to avoid sending routes with invalid AS_PATHs. The procedure is modified so that it simulates what may be the outcome of the ASPA-based AS_PATH Verification done later by other networks.¶

The egress AS_PATH Verification SHOULD be performed on all routes possibly eligible for being propagated at egress, not just the current best route. This would help detecting misconfiguration in early stages of deployment, and generally prevent the case of unexpected backup link failure.¶

The egress AS_PATH Verification MUST be performed on the AS_PATH already updated according to [RFC4271], section 5.1.2. That ensures that the route looks like what the neighboring AS would receive from the egress speaker.¶

If the neighboring AS is a Provider or a Peer, or a (transparent or non-transparent) Route Server (RS) while the egress speaker is an RS-client, the egress speaker runs the Upstream Verification Procedure, as specified in [I-D.ietf-sidrops-aspa-verification], section 5.4. If the neighboring AS is a Customer, the egress speaker runs the Downstream Verification Procedure.¶

To select the appropriate verification procedure, the egress speaker needs reliable information about the relationship between the local AS and the egress neighbor AS. This information may be obtained from BGP Role capabilities exchanged in the BGP OPEN message, ASPA objects registered by the local AS and the external neighbor AS, or local BGP peering and export-policy configuration.¶

If the relationship is Complex, the egress speaker SHOULD logically segregate the single eBGP session into regular BGP Roles, and then apply the verification procedures accordingly. If such a segregation is not feasible, the egress speaker SHOULD determine the appropriate verification procedure on a per-prefix basis. If this determination is not feasible as well, then an operator MAY apply the algorithm for downstream paths to avoid false positive outcomes.¶

In all cases, if the AS_PATH Verification result is Invalid, the egress speaker SHOULD NOT propagate the affected route to that specific neighbor, and a notification SHOULD be sent to the human operators of the network.¶

4.2. Neighbor-AS-Augmented Verification

For operational assurance, especially to detect missing Provider ASes in ASPA records, an implementation or detached verification system (see Section 5.1) SHOULD support a verification mode that, for the process of verification only, also prepends the neighboring AS number when the neighboring AS is a Provider or a Customer. Otherwise, if the provider-customer relationship is not properly reflected in the published ASPA, the route may fail AS_PATH Verification later, as described in Section 3.2.¶

This neighbor-AS-augmented verification is most naturally used in detached, offline, or monitoring configurations. Use of this mode for inline egress enforcement is a matter of local policy and should consider router processing cost, deployment maturity, and the operator's intended treatment of Invalid results.¶

5.1. Centralized or Detached Verification

If the network has a BGP Route Reflector ([RFC4456]) or another centralized control-plane node, the egress ASPA processing may be offloaded to that node. This is feasible only when the verifying node has sufficient per-egress context, including the egress ASBR, the local AS number used at that egress point, the neighboring AS number, the applicable BGP Role or local relationship, and any export-policy context needed to simulate the egress AS_PATH. Without this metadata, centralized verification may be incomplete or inefficient, and is primarily useful for monitoring and operational assurance unless it can affect the actual egress ASBR's export decision.¶

It is also possible to collect routes by other means, e.g. by the BGP Monitoring Protocol[RFC7854], and run the verification in a completely detached configuration. While this configuration doesn't allow for immediate route withdrawal in case of the verification result being Invalid, it keeps the optimization advantages and allows for easy notifications.¶

5.2. Deployment Controls

Operators may need controls to enable, disable, or change the enforcement mode of egress verification as deployment evolves. Such controls are deployment controls, not a replacement for the verification procedure. For example, an operator may choose alert-only or detached verification when the goal is operational assurance, or may disable inline egress verification for a class of routes once the relevant ingress ASPA verification and OTC or equivalent intra-AS leak-prevention marking are deployed and the remaining motivation is already covered by local policy.¶

Such controls only affect how this document's egress verification is enforced for selected routes or sessions. They do not disable ASPA, OTC, or ingress ASPA verification, and they do not imply that ASPA-based verification is unnecessary. They are not appropriate for scenarios where the operator still wants egress verification to detect AS migration mistakes, AS_PATH manipulation mistakes, ASPA registration omissions, or other export-side operational errors.¶

5.3. Partial Verification

For routes received by the local AS from outside, part of the AS_PATH should have been already validated by the ingress BGP speaker. If the verifying node can determine which prefix of the AS PATH is not yet verified, it MAY skip re-verifying the received part of the path, and compose the ingress result with the local part. Otherwise, the verifier should perform full AS_PATH verification. Partial verification is a scoped optimization, not a relaxation of ASPA-based AS_PATH verification.¶

For the simple case as described in Section 4, the egress verification procedure would check the local AS number and, when neighbor-AS-augmented verification is used, the neighbor's AS number against the local ASPA database. This procedure SHOULD be automated based on the BGP Role setting for that specific neighbor, even if the other side doesn't support the BGP Role capability.¶

1. If the local AS is a Customer of the neighbor AS, which is a Provider, then all the routes sent by local AS to the neighbor will end up having an AS_PATH (… P, C, …) where at least the maximum up ramp extends at least to P. Therefore, the simple partial verification SHOULD periodically check whether P is indeed not NotProvider+ of C.¶
2. If the local AS is a Provider of the neighbor AS, which is a Customer, then all the routes sent by local AS to the neighbor will end up having an AS_PATH (… C, P, …), where at least the maximum down ramp extends at least to P. Therefore, the simple partial verification SHOULD periodically check whether P is indeed not NotProvider+ of C.¶
3. If the local AS is a lateral Peer of the neighbor AS, which is therefore also a Peer, there is no need for any check, as well as if the local AS is a Route Server Client.¶

In case of failure of the simple periodic check, described in previous paragraphs, the affected node SHOULD NOT propagate any route over the affected eBGP session. The verifying node (which may be a different node) SHOULD notify both the affected node and the human operators of the network.¶

If the network does some complex AS_PATH modification (e.g., during AS merges, splits, or renumbering transitions), the operator should do a proper assessment of possible partial verification approaches, which may include the aforementioned pair verifications, and maybe other verifications as well. In such cases, it is recommended to verify the full AS_PATH, since registration errors or omissions frequently occur during these transitions. The full extent of possible verifications is out of scope of this document.¶