| Internet-Draft | Dynamic Risk Indication & Propagation | September 2026 |
| Geng, et al. | Expires 24 March 2027 | [Page] |
This document specifies a framework and associated protocol extensions for dynamic routing risk propagation and automated mitigation in BGP networks. Building upon Resource Public Key Infrastructure (RPKI) Route Origin Validation (ROV), this specification defines mechanisms to associate abnormal or hijacked routes with related routing entities (e.g., ASes or BGP peers) to dynamically depreference associated paths. Furthermore, it introduces extensions to the RPKI-to-Router (RTR) protocol and BGP Path Attributes to feedback, distribute, and signal ROA risk indicators across Relying Parties (RPs) and BGP Routers, enabling proactive and coordinated threat mitigation across network boundaries.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 24 March 2027.¶
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.¶
Resource Public Key Infrastructure (RPKI) Route Origin Validation (ROV) [RFC6811] allows BGP routers to determine the authorization state of an origin AS for a given IP prefix. However, standard ROV treats routes in isolation: an 'Invalid' validation state results in dropping or depreferencing only the specific invalid route.¶
In practice, route leaks and BGP hijacks often indicate a broader compromise or misconfiguration involving an entire Autonomous System (AS) or a specific BGP peer. Continuing to prefer other routes from the same suspect origin or peer leaves the network vulnerable to secondary attacks or propagation delays.¶
This document addresses these limitations by specifying four complementary schemes to detect, signal, and automatically mitigate routing risks dynamically:¶
RP (Relying Party): An RPKI cache validator that collects, validates, and maintains RPKI data.¶
ROV (Route Origin Validation): The process defined in [RFC6811].¶
Risk-Tagged ROA: A validated ROA payload augmented with metadata indicating suspect validity, elevated risk, or active hijack association.¶
Risk Score / Risk Tag: An indicator associated with an AS, peer, or prefix signaling potential routing security threats.¶
The architecture creates a closed-loop security framework spanning the Relying Party (RP), local routers, and peer routers.¶
+-------------------+
| Relying Party |
| (RP) |
+-------------------+
|| (Sch 3: Risk) ^
|| || (Sch 2: Feedback)
\/ ||
+--------------------------+
| Local Router |
+--------------------------+
|| (Sch 4: Risk Comm)
\/
+--------------------------+
| Peer Router |
+--------------------------+
- Scheme 1 operates locally on the Local Router.
- Scheme 2 provides feedback from Local Router to RP via RTR.
- Scheme 3 propagates risk-tagged ROA from RP to Local Router via RTR.
- Scheme 4 signals risk status between BGP Routers via BGP Community.
¶
When a router identifies a hijacked or invalid route using RPKI ROV (or other detection mechanisms such as ASPA [I-D.ietf-sidrops-aspa-verification] or local anomaly detectors), it MUST mark the route as Invalid or Suspect.¶
Under Scheme 1, the router automatically correlates the invalid route with related routes sharing structural attributes, including:¶
The same Origin AS (AS_PATH last element).¶
The same immediate Neighbor AS or BGP Peer.¶
The same AS_PATH sequence pattern.¶
Upon identifying associated routes, the router's decision process SHOULD dynamically adjust their selection criteria (e.g., reducing the Local_Pref value) to depreference those routes in favor of alternative, unaffected paths.¶
When a BGP router detects an Invalid route or an active hijack attempt, it MAY generate a Risk Feedback signal sent to its connected RP via an extended RPKI-to-Router (RTR) protocol session [RFC8210].¶
The feedback message MUST contain:¶
The affected Prefix and Length.¶
The suspect Origin AS / Peer AS.¶
The associated ROA Payload identifier.¶
A Risk Reason Code (e.g., ROV Invalid, Unexpected AS-Path Hop).¶
Upon receiving the feedback signal, the RP MUST verify the local telemetry and update its internal ROA risk database. The RP MAY recalculate the confidence score of the corresponding ROA entries or flag the ROA as "State: Elevated Risk".¶
The RP MAY distribute Risk-Tagged ROA records to client routers using extended RTR PDUs. A Risk-Tagged ROA conveys that while a valid cryptographic signature exists, operational intelligence indicates elevated risk.¶
Upon receiving a Risk-Tagged ROA entry from the RP, a router:¶
When Router-1 detects an invalid/hijacked route or receives a risk-tagged instruction, it MAY notify adjacent BGP routers (Router-2, Router-3) by attaching a BGP Attribute or Extended Community to BGP UPDATE messages.¶
The signaling format MUST use the BGP Routing Risk Extended Community defined in Section 5.2.¶
Upon receiving a route carrying the BGP Routing Risk Extended Community, a receiving router MUST evaluate local import policy. If configured to honor inter-domain risk signals, the router SHOULD:¶
This document extends the RPKI-to-Router Protocol (RTR v1 [RFC8210]) by defining two new PDU types:¶
0x0B: Router Risk Feedback PDU (Router -> RP)¶
0x0C: Risk-Tagged IPv4/IPv6 Prefix PDU (RP -> Router)¶
The Risk PDU payload format is defined as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (2) | PDU Type(0x0C)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Prefix Length | Max Length | Risk Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This document defines a new Transitive Opaque Extended Community termed the "BGP Routing Risk Extended Community":¶
- Type: 0x03 (Transitive Opaque Extended Community)¶
- Sub-Type: To Be Determined by IANA¶
- Value: 2-octet Risk Sub-code, 4-octet Target AS/Peer ID.¶
Propagating risk signals dynamically introduces potential denial-of-service (DoS) vectors if malicious or misconfigured nodes inject false risk warnings.¶
To mitigate unauthorized risk signaling:¶
RTR sessions carrying Risk PDUs MUST use transport layer protection (e.g., SSH or TLS as mandated in [RFC8210]).¶
Inter-domain BGP Risk Extended Communities SHOULD be stripped at eBGP boundaries unless explicitly permitted by bilateral trust agreements.¶
Depreferencing algorithms MUST enforce a minimum Local_Pref floor to prevent total blackholing of legitimate traffic unless explicit hard filtering policies are specified.¶
IANA is requested to allocate:¶
Two new PDU Types in the "RTR Protocol PDU Types" registry (0x0B, 0x0C).¶
A new Sub-Type for the BGP Routing Risk Extended Community under the "Transitive Opaque Extended Community Sub-Types" registry.¶
This document requests IANA to perform the following actions:¶
The authors would like to thank the IETF SIDROPS Working Group members for their valuable feedback and discussion.¶