]> Zhongguancun Laboratory

Beijing China zhangj@mail.zgclab.edu.cn

Tsinghua University

Beijing China wangyy@cernet.edu.cn

CZ.NIC

Czechia maria.matejka@nic.cz

Tsinghua University

Beijing China xmw@cernet.edu.cn

USA National Institute of Standards and Technology

100 Bureau Drive Gaithersburg MD 20899 United States of America ksriram@nist.gov

Huawei

Beijing China gengnan@huawei.com

Operations and Management Area (OPS) SIDR Operations Working Group BGP ASPA Route leak This document describes AS_PATH verification based on Autonomous System Provider Authorization (ASPA) for egress eBGP speakers. ASPA is a Resource Public Key Infrastructure (RPKI) object that allows an AS to register its transit provider ASes. Performing ASPA-based AS_PATH verification at egress can prevent inadvertent propagation of route leaks to external peers, check for local misconfigurations, and help detect potential ASPA registration errors. This approach complements ingress-side verification and BGP Roles/Only to Customer (OTC); it also provides operational assurance for partial deployment and for export-side configuration or registration problems.

Introduction Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) can be used to verify BGP AS_PATH for detection and mitigation of route leaks and certain prefix hijacks involving forged origins or forged path-segments . The ASPA object profile is defined in . Section 5 of describes the procedures to perform ASPA-based BGP AS_PATH verification at eBGP ingress. This document additionally explains the reasons, use cases, scenarios, variants and specifics of ASPA-based BGP AS_PATH verification at eBGP egress and in detached or monitoring configurations, in a similar way as did with RPKI route origin validation (RPKI-ROV) for BGP export. This document does not change the semantics or procedures of ASPA-based BGP AS_PATH verification defined in . It is not intended to question the adequacy of ingress ASPA verification. Egress verification is an additional local assurance mechanism for export behavior, partial deployment, and operational error detection.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Suggested Reading It is assumed that the reader understands BGP, RPKI, ASPA object profile, ASPA-based BGP AS_PATH verification, RPKI-ROV for BGP export, and BGP Roles. The definitions of Customer, Provider, Route Server, Route Server Client and Peer, used in this document, are the same as in BGP Roles.

Problem Statement ASPA-based AS_PATH verification at eBGP egress is motivated by multiple operational scenarios. In partial deployment, some ingress ASBRs may not yet support ASPA verification or BGP Roles while some egress ASBRs or detached verification systems do. Egress verification may then provide useful coverage for routes that would otherwise leave the AS without ASPA-based export checks. Operational assurance is another motivation: locally originated routes, ASPA registration mistakes, local AS number mistakes, AS migration, and export policy or AS_PATH manipulation may cause a route that was valid on ingress, or was never checked on ingress, to become invalid once exported to neighbors. The AS_PATH verification errors may happen in a subtle way, e.g. on routes propagated only to one neighbor, or even routes intended as backup, ordinarily not selected as best. This is a difference compared to Route Origin Verification where errors are often seen nicely in public BGP analysis tools.

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.

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 , 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 , 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.

Missing Provider illustration

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.

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 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.

Procedure of ASPA-based AS_PATH Verification at eBGP Egress

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 , 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 , 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.

Neighbor-AS-Augmented Verification For operational assurance, especially to detect missing Provider ASes in ASPA records, an implementation or detached verification system (see ) 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 . 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.

Optimizations Running AS_PATH Verification for all routes at all eBGP egress may hamper routing performance and cause unnecessary propagation delays. In order to make the verification possible on larger scales, there are several approaches to optimize the verification process. Optimized egress verifications, if deployed properly, are sufficient to detect both ASPA misconfigurations and AS Path manipulation errors.

Centralized or Detached Verification If the network has a BGP Route Reflector () 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, 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.

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.

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 , 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.

Using the Only to Customer (OTC) Attribute This document does not replace BGP Roles and the Only to Customer (OTC) BGP Attribute. It is expected that the ingress BGP speaker marks the routes received on ingress accordingly, either by OTC, or by some other means (e.g. Large Communities). If the routes are not marked, the egress verification procedure described above may produce incorrect results.

Illustration of eBGP ingress, iBGP propagation, and eBGP egress. >| R1 |------->>| R2 |-------->>| AS Y | +-------+ | +----+ +----+ | +--------+ | | +------------------------+ eBGP ingress eBGP egress ]]>

In , R1 has direct local knowledge of the relationship between AS X and AS(N), while R2 may only have the route as propagated inside AS X. If the route is marked by OTC or by an equivalent intra-AS leak-prevention signal, that marking MUST take precedence over the outcome of egress ASPA verification. In particular, if the marking says that the route MUST NOT be exported to the egress neighbor, the egress speaker MUST NOT export the route based on a Valid egress ASPA result. Specifically, while providers are easily distinguishable from the local network's ASPA record, it is impossible to tell whether a specific neighboring network is a customer or a peer, if they have not signed their ASPA. With that, it's impossible and undesirable to replace OTC by ASPA-based AS_PATH Verification on BGP egress.

Operational Considerations The ASPA-based AS_PATH verification on eBGP egress is not a complete solution on its own. There may be both false positive and false negative results arising from e.g. outdated ASPA database, or superfluous providers in an ASPA record. The records also do change over time and the verification results with them. It is expected that the operators will closely monitor all Invalid ASPA verification results, and act accordingly. In most cases, these results are caused by human errors, either local, or by a neighboring network. If the operators determine that the Invalid result is caused by a neighboring network, they SHOULD notify the operators of that network in a timely manner. If it is necessary to have an eBGP session with Complex relationship, including mutual-transit arrangements, the operators should take extra care properly documenting and designing the appropriate local modifications of the ASPA and OTC procedures. ASPA objects can represent mutual provider authorization at the AS level, while OTC and BGP Roles are session oriented and may require segregating the relationship into non-Complex sessions where feasible. This document does not define additional BGP Roles or OTC behavior for these cases. It is generally not recommended to switch ASPA and OTC off for these links without having a proper alternative. Notably, route server BGP sessions may easily become a Complex relationship if any of the peers there becomes a provider, while others stay as peers .

Security Considerations The security considerations that apply to ASPA-based AS_PATH verification (see ) also apply to the procedure described in this document.

IANA Considerations This document has no IANA actions

References Normative References &I-D.ietf-sidrops-aspa-profile; &I-D.ietf-sidrops-aspa-verification; Informative References BGP is the protocol that keeps Internet connected. Operators use it by announcing Address Prefixes (APs), namely IP address blocks, that they own or that they agree to serve as transit for. BGP enables ISPs to devise complex policies to control what AP announcements to accept (import policy), the route selection, and what AP to announce and to whom (export policy). In addition, BGP is also used to coarse traffic engineering for incoming traffic via the prepend mechanism. However, there are no wide-spread good tools for managing BGP and much of the complex configuration is done by home- brewed scripts or simply by manually configuring router with bare-bone terminal interface. This process generates many con- figuration mistakes. In this study, we examine typos that propagates in BGP an- nouncements and can be found in many of the public databases. We classify them and quantify their presence, and surprisingly found tens of ASNs and hundreds of APs affected by typos on any given time. In addition, we suggest a simple algorithm that can detect (and clean) most of them with almost no false positives.

Acknowledgements The authors thank Randy Bush for his valuable suggestions and comments.