Enhanced AS-Loop Detection for BGP

3.1. AS Loop Detected at Inbound Processing

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

   AS-Loop-Detection Applied Here:
   Discard AS-Loop routes directly if AS_PATH contains AS64596
                 |
                 |                                  x.y.z.0/24
                 v                                  Origin AS 64600
AS64595---AS64596---AS64597---AS64598---AS64599----AS64600
                    From AS64597, To AS64596:
                    Normal Case:
                    <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600

                    Forged Case 1:
                    <-- x.y.z.0/24, AS-Path: 64597 64596
                                        (Or: 64597 64598 64596 etc.)

                    Forged Case 2:
                    <-- x.y.z.0/24, AS-Path: 64597 64596 64600
                                        (Or: 64597 64596 64599 64600 etc.)

    Figure 1: BGP Inbound Route Processing in AS64596

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

3.2. AS Loop Detected at Outbound Processing

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

   Split-Horizon Enabled & AS-Loop-Detection Applied Here:
   Discard AS-Loop routes directly if outbound AS_PATH contains AS64596
                    |
                    |                               x.y.z.0/24
                    v                               Origin AS 64600
AS64595---AS64596---AS64597---AS64598---AS64599----AS64600
                    From AS64597, To AS64596:
                    Normal Case:
                    <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600

                    Forged Case 3:
                    <-- x.y.z.0/24, AS-Path: 64597 64596
                                        (Or: 64597 64598 64596 etc.)

                    Forged Case 4:
                    <-- x.y.z.0/24, AS-Path: 64597 64596 64600
                                        (Or: 64597 64596 64599 64600 etc.)

    Figure 2: BGP Outbound Route Processing in AS64597

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

4.1. Enhancement for AS Loop Detected at Inbound Processing

While Route Origin Validation (ROV) [RFC6811] and ASPA verification [I-D.ietf-sidrops-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.¶

4.2. Enhancement for AS Loop Detected at Outbound Processing

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

5.1. BMP Support for Monitoring AS Path Looped UPDATE Messages

Per [RFC7854], BMP Route Mirroring messages convey BGP UPDATE messages that have been discarded or modified due to errors (such as treat-as-withdraw [RFC7606]) 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.¶

+---------------------------------------------------------------+
|         Common BMP Header (Message Type = 6)                  |
+---------------------------------------------------------------+
|                    Per peer Header                            |
+---------------------------------------------------------------+
| Information TLV (Type = 1) with Code = TBD: AS Path Looped    |
+---------------------------------------------------------------+
|         BGP Message TLV (Type = 0)                            |
+---------------------------------------------------------------+

Figure 3: AS Path Looped UPDATE Message Enclosed in BMP Route
Mirroring

5.2. Operational Application Example

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

                        +------------+
                        | BMP server |
                        |     +      |
                        |  Analyzer  |
                        +------+-----+
   BMP Mirroring Message:      \
   AS Path Looped Update Message\to BMP Server
                                 \
                                  \
               ********************|****
               *                   |   *
               *          AS64596  |   *        "AS64597 Send Routes
               *                   |   *  <----- to AS64596"
  +-------+    *  +---+         +---+  *  +-------+
  +AS64595+-------+ R1+---------+ R2|-----+AS64597+---64598 64599 64600
  +-------+    *  +-+-+\        +---+  *  +-------+
               *    |   \\    //  |\   *
               *    |     \\//    | \  *
               *    |     //\     |  \ *      +-------+
               *    |   //   \\   |   \+------+AS64593+
               *    |  /       \  |    *      +-------+
  +-------+    *  +-+-+         +-+-+  *      +-------+
  +AS64594+----+--+ R3+---------+ R4+---------+AS64592+
  +-------+    *  +---+         +---+  *      +-------+
               *                       *
               *************************

Figure 4: Centralized AS-Loop Detection Architecture

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

+--------------------------------------------------+
|   Neighboring AS  |  AS-relationship to AS64596  |
+--------------------------------------------------+
|   64592           |  P2P                         |
+--------------------------------------------------+
|   64593           |  S2S                         |
+--------------------------------------------------+
|   64594           |  C2P                         |
+--------------------------------------------------+
|   64595           |  P2C                         |
+--------------------------------------------------+
|   64597           |  P2P                         |
+--------------------------------------------------+

Figure 5: AS64596 Local AS-Relationship Database

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