Enhanced AS-Loop Detection for BGP

In ordinary BGP operations, every AS announces route information with specific prefixes. However, neighboring ASes typically cannot validate the authenticity of this route information, leading them to either propagate it across the Internet or blindly discard AS-looped routes. This weak trust model allows forged route announcements to propagate undetected, representing a fundamental security vulnerability in BGP. Forged routes, whether generated by configuration errors or malicious attacks, can lead to large-scale network connectivity disruptions. In more severe scenarios, attackers exploit this BGP property to execute **AS-Path Poisoning** attacks. By inserting targeted transit or provider AS numbers into a forged `AS_PATH`, attackers attempt to make routes appear as though they legitimately traversed those ASes, or conversely, to prevent those ASes from accepting and carrying the route. Autonomous System Provider Authorization (ASPA) provides a systematic, RPKI-based mechanism to verify the `AS_PATH` attribute of BGP routes. However, ASPA requires comprehensive infrastructure deployments across the routing ecosystem. This document proposes enhancing BGP inbound and outbound route processing upon detecting an AS loop to identify potential BGP hijacks immediately. By retaining and analyzing routes that trigger AS loop detection instead of silently discarding them, operators can gain immediate visibility into malicious activities without waiting for full global PKI infrastructure adoption.

The following terminology is used in this document. AS: Autonomous System ASPA: Autonomous System Provider Authorization BGP: Border Gateway Protocol BGP hijacking : is the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables maintained using the Border Gateway Protocol (BGP). (Sometimes referred to as prefix hijacking, route hijacking or IP hijacking) EBGP: External BGP ISP: Internet Service Provider BMP: BGP Monitoring Protocol ROA: Route Origin Authorization

The cases below illustrate scenarios where an upstream AS advertises an invalid AS_PATH to AS64596: Forged Case 1 (Origin Spoofing): An upstream AS of AS64596 advertises a route with ASN 64596 forged as the origin AS in the AS_PATH. Forged Case 2 (Transit Spoofing): An upstream AS of AS64596 advertises a route with ASN 64596 forged as a transit AS in the AS_PATH.

Upon receiving these updates, standard BGP implementations treat them as ordinary routing loops and silently discard them during the loop detection phase. In most Network Operating Systems (NOSes), such dropped routes are neither logged nor exposed via standard management interfaces, remaining visible only when debugging modes are enabled. By enhancing the inbound processing mechanism, AS64596 can proactively identify instances where its own ASN has been spoofed, preventing undetected routing anomalies or path manipulation.

eBGP Split-Horizon is an optional policy mechanism wherein a BGP speaker suppresses route updates to a peer if that peer's AS is already present in the AS_PATH. In existing implementations, outbound BGP processing silently drops such updates once an AS loop is detected. Forged Case 3 (Outbound Origin Spoofing): An upstream AS of AS64597 advertises a route to AS64597 that forges ASN 64596 as the origin AS in the AS_PATH. Forged Case 4 (Outbound Transit Spoofing): An upstream AS of AS64597 advertises a route to AS64597 that forges ASN 64596 as a transit AS in the AS_PATH.

When preparing outbound advertisements to AS64596, AS64597 detects the presence of AS64596 in the AS_PATH and silently suppresses transmission. With enhanced outbound processing, AS64597 can recognize that AS64596 has been spoofed upstream. This allows network operators to identify malicious path poisoning or accidental loop creation before it impacts downstream connectivity.

While Route Origin Validation (ROV) and ASPA verification offer systematic protection against BGP route leaks and hijacks, conventional inbound processing drops AS-looped updates prior to applying validation checks. Consequently, routes matching Forged Cases 1 and 2 are discarded prematurely. This document proposes intercepting and inspecting these looped updates before disposal. Additional security mechanisms (e.g., ROV or ASPA) can then be applied to evaluate whether the update represents a malicious attack or a configuration anomaly. The exact validation criteria and remediation actions are outside the scope of this document. Two deployment models are defined for inbound processing enhancements: Option 1 (On-Device Inspection): Perform local validation and security analysis directly on the router using local threat intelligence databases or cache instances. Option 2 (Centralized Telemetry): Export the intercepted AS-looped updates via the BGP Monitoring Protocol (BMP) to a remote network controller or collector for off-box analysis.

Egress ROV and ASPA checks can similarly prevent the propagation of hijacked routes. However, when eBGP Split-Horizon or outbound loop prevention is active, routes matching Forged Cases 3 and 4 are suppressed prior to outbound security validation. This document proposes extending outbound processing to capture suppressed updates for further security inspection. Evaluating these suppressed routes enables network operators to detect path poisoning aimed at deliberately blocking route propagation. Two deployment models are defined for outbound processing enhancements: Option 1 (On-Device Inspection): Evaluate outbound suppressed routes directly on the local router against configured policy or validation databases. Option 2 (Centralized Telemetry): Stream suppressed outbound update metadata via BMP to a centralized monitoring system or security platform for cross-network correlation.

Considering the scaling and management challenges associated with maintaining localized validation databases across distributed network elements, this section proposes a centralized telemetry framework. The approach leverages the BGP Monitoring Protocol (BMP) to stream intercepted AS Path Looped UPDATE messages from monitored routing nodes to a centralized BMP server, enabling enterprise-wide or provider-wide attack detection and security analytics. BMP is widely deployed by Internet Content Providers (ICPs), Over-The-Top (OTT) service providers, and Tier-1/2 Carriers to monitor active BGP routing state, such as monitoring Adj-RIB-In and Adj-RIB-Out . This document extends the BMP Route Mirroring Message framework to mirror UPDATE messages that trigger AS loop detection events to the BMP collector.

Per , BMP Route Mirroring messages convey BGP UPDATE messages that have been discarded or modified due to errors (such as treat-as-withdraw ) for offline debugging and diagnostic analysis. This document extends Route Mirroring to mirror updates suppressed due to AS loop detection. This document defines a new code for the BMP Information TLV (Type 1): Code = TBD: AS Path Looped. Indicates that the encapsulated BGP UPDATE message in the Route Mirroring message contains an AS loop involving the local AS (detected during either inbound or outbound processing). The BMP payload structure follows standard RFC 7854 encapsulation: the Common BMP Header (Message Type = 6) and Per-Peer Header are immediately followed by an Information TLV (Type = 1) with Code = TBD (AS Path Looped), which precedes the BGP Message TLV (Type = 0) carrying the complete, unedited BGP UPDATE message.

Figure 4 illustrates a centralized deployment workflow. When router R2 in AS64596 receives an UPDATE from an eBGP peer in AS64597 that contains AS64596 in the AS_PATH, the inbound AS loop detection logic triggers. Rather than silently dropping the update without a trace, R2 encapsulates the UPDATE message inside a BMP Route Mirroring message carrying the "AS Path Looped" Information TLV and streams it to the centralized BMP server. An external security analyzer consumes the telemetry feed from the BMP server to perform real-time threat detection and route leak/hijack correlation.

To detect whether an AS loop indicates malicious AS_PATH forgery or legitimate topology traversal, the central analyzer evaluates the looped update against a local Autonomous System Relationship Database maintained by AS64596 (Figure 5). This database tracks peering arrangements (e.g., Customer-to-Provider (C2P), Peer-to-Peer (P2P), Provider-to-Customer (P2C), or Sibling-to-Sibling (S2S)).

When AS64596 appears as a transit AS within an intercepted AS_PATH, the path segment around the local AS exhibits the following structure: [... Other ASes ...], AS_Left, Local_AS (64596), AS_Right, [... Other ASes ...] The analyzer looks up `AS_Left` and `AS_Right` in the database to verify whether established business relationships authorize adjacency with `Local_AS`. If no valid relationship exists between `AS_Left` and `Local_AS`, or between `Local_AS` and `AS_Right`, the system identifies the route as a spoofed path or unauthorized route leak and initiates automated mitigation policies.

Enhancing BGP inbound and outbound processing to intercept, log, and stream AS-looped UPDATE messages yields substantial security and operational benefits: Immediate Threat Visibility: Eliminates the telemetry blind spot caused by silent drops during routine loop checks, providing real-time awareness of active AS_PATH forgery and path poisoning attacks. Incremental Deployment: Enables individual Autonomous Systems to detect path manipulation targeting their own ASNs immediately, without depending on global adoption of RPKI, ROV, or ASPA infrastructure. Enhanced Troubleshooting: Provides network engineering and security operations teams with detailed diagnostic data to differentiate between accidental operator configuration errors and deliberate route hijacks.

The authors would like to acknowledge the reviews, feedback, and contributions from Gang Yan, Zhenbin Li, Aijun Wang, Jeff Haas, Robert Raszuk, Chris Morrow, Alexander Azimov, Ruediger Volk, Jescia Chen, and members of the IETF IDR Working Group.

This document requests IANA to assign a new code value in the **BMP Information TLV - Type 1 (Information) Code** registry: Code = TBD: AS Path Looped.

This document does not change the underlying security issues in the BGP protocol. It however, does provide an additional mechanism to protect against attacks based on the forged AS-Path in the BGP routes.

The following people made significant contributions to this document: Yunan Gu Huawei Email: guyunan@huawei.com