Skip to main content

Enhanced AS-Loop Detection for BGP
draft-chen-grow-enhanced-as-loop-detection-09

Document Type Active Internet-Draft (individual)
Authors Huanan Chen , Di Ma , Nan Geng , Shunwan Zhuang , Haibo Wang
Last updated 2026-08-31
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-grow-enhanced-as-loop-detection-09
Global Routing Operations                                        H. Chen
Internet-Draft                                             China Telecom
Intended status: Standards Track                                   D. Ma
Expires: 4 March 2027                                               ZDNS
                                                                 N. Geng
                                                               S. Zhuang
                                                                 H. Wang
                                                                  Huawei
                                                          31 August 2026

                   Enhanced AS-Loop Detection for BGP
             draft-chen-grow-enhanced-as-loop-detection-09

Abstract

   Misconfiguration and malicious manipulation of the BGP `AS_PATH`
   attribute can lead to route hijacking.  This document proposes
   enhancements to BGP [RFC4271] inbound and outbound route processing
   when an AS loop is detected.  This mechanism can be implemented
   directly on devices or deployed in a centralized architecture using
   the BGP Monitoring Protocol (BMP) [RFC7854].  These enhancements
   empower networks to quickly and accurately detect route hijacking and
   malicious path poisoning.

   Two implementation options are proposed:

   1.  Local validation and checking directly on the routing device.

   2.  Centralized data collection and analysis via a remote network
       controller or server.

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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Chen, et al.              Expires 4 March 2027                  [Page 1]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Forged AS_PATH Examples . . . . . . . . . . . . . . . . . . .   4
     3.1.  AS Loop Detected at Inbound Processing  . . . . . . . . .   4
     3.2.  AS Loop Detected at Outbound Processing . . . . . . . . .   5
   4.  Enhancement to BGP Inbound/Outbound Processing  . . . . . . .   6
     4.1.  Enhancement for AS Loop Detected at Inbound Processing  .   6
     4.2.  Enhancement for AS Loop Detected at Outbound
           Processing  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Centralized AS-Loop Detection for BGP . . . . . . . . . . . .   7
     5.1.  BMP Support for Monitoring AS Path Looped UPDATE
           Messages  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Operational Application Example . . . . . . . . . . . . .   8
   6.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Chen, et al.              Expires 4 March 2027                  [Page 2]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

1.  Introduction

   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)
   [I-D.ietf-sidrops-aspa-verification] 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.

2.  Terminology

   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)

Chen, et al.              Expires 4 March 2027                  [Page 3]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   EBGP: External BGP

   ISP: Internet Service Provider

   BMP: BGP Monitoring Protocol

   ROA: Route Origin Authorization

3.  Forged AS_PATH Examples

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

Chen, et al.              Expires 4 March 2027                  [Page 4]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   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

Chen, et al.              Expires 4 March 2027                  [Page 5]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   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.  Enhancement to BGP Inbound/Outbound Processing

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.

Chen, et al.              Expires 4 March 2027                  [Page 6]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   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.  Centralized AS-Loop Detection for BGP

   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) [RFC7854] 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 [RFC7854] and
   Adj-RIB-Out [RFC8671].  This document extends the BMP Route Mirroring
   Message framework [RFC7854] to mirror UPDATE messages that trigger AS
   loop detection events to the BMP collector.

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):

Chen, et al.              Expires 4 March 2027                  [Page 7]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

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

Chen, et al.              Expires 4 March 2027                  [Page 8]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

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

Chen, et al.              Expires 4 March 2027                  [Page 9]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

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

6.  Benefits

   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.

Chen, et al.              Expires 4 March 2027                 [Page 10]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   *  Enhanced Troubleshooting: Provides network engineering and
      security operations teams with detailed diagnostic data to
      differentiate between accidental operator configuration errors and
      deliberate route hijacks.

7.  Acknowledgements

   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.

8.  IANA Considerations

   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.

9.  Security Considerations

   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.

10.  Contributors

   The following people made significant contributions to this document:

   Yunan Gu

   Huawei Email: guyunan@huawei.com

11.  Normative References

   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
              J., and K. Sriram, "BGP AS_PATH Verification Based on
              Autonomous System Provider Authorization (ASPA) Objects",
              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
              verification-28, 24 August 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-28>.

Chen, et al.              Expires 4 March 2027                 [Page 11]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8671]  Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S.
              Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring
              Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November
              2019, <https://www.rfc-editor.org/info/rfc8671>.

Authors' Addresses

   Huanan Chen
   China Telecom
   109, West Zhongshan Road, Tianhe District
   Guangzhou
   510000
   China
   Email: chenhuan6@chinatelecom.cn

Chen, et al.              Expires 4 March 2027                 [Page 12]
Internet-Draft         Enhanced AS-Loop Detection            August 2026

   Di Ma
   ZDNS
   4 South 4th St. Zhongguancun
   Beijing
   Haidian,
   China
   Email: madi@zdns.cn

   Nan Geng
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: gengnan@huawei.com

   Shunwan Zhuang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhuangshunwan@huawei.com

   Haibo Wang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: rainsword.wang@huawei.com

Chen, et al.              Expires 4 March 2027                 [Page 13]