SIDROPS N. Geng Internet-Draft L. Dai Intended status: Standards Track H. Wang Expires: 24 March 2027 S. Zhuang Huawei Technologies 20 September 2026 Dynamic Risk Indication and Propagation in BGP (DRIP) draft-geng-sidrops-bgp-drip-00 Abstract 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. 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. 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." Geng, et al. Expires 24 March 2027 [Page 1] Internet-Draft Dynamic Risk Indication & Propagation September 2026 This Internet-Draft will expire on 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 4. Detailed Operational Schemes . . . . . . . . . . . . . . . . 4 4.1. Scheme 1: Local Peer/AS Association and Preference Reduction . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Scheme 2: Router-to-RP Risk Feedback Mechanism . . . . . 5 4.3. Scheme 3: RP-to-Router Risk-Tagged ROA Propagation . . . 5 4.4. Scheme 4: Inter-Router BGP Risk Attribute Propagation . . 5 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 5.1. RTR Protocol Extensions (RTR Risk PDU) . . . . . . . . . 6 5.2. BGP Routing Risk Extended Community . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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. Geng, et al. Expires 24 March 2027 [Page 2] Internet-Draft Dynamic Risk Indication & Propagation September 2026 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: 1. Associated Path Depreference based on local ROV anomaly detection. 2. Router-to-RP feedback loop for updating local ROA risk tables. 3. RP-to-Router propagation of risk-tagged ROA entries. 4. Inter-domain and intra-domain BGP signaling of risk states via a new BGP Path Attribute or Extended Community. 2. Terminology * 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. 3. Architecture Overview The architecture creates a closed-loop security framework spanning the Relying Party (RP), local routers, and peer routers. Geng, et al. Expires 24 March 2027 [Page 3] Internet-Draft Dynamic Risk Indication & Propagation September 2026 +-------------------+ | 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. 4. Detailed Operational Schemes 4.1. Scheme 1: Local Peer/AS Association and Preference Reduction 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. Geng, et al. Expires 24 March 2027 [Page 4] Internet-Draft Dynamic Risk Indication & Propagation September 2026 4.2. Scheme 2: Router-to-RP Risk Feedback Mechanism 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". 4.3. Scheme 3: RP-to-Router Risk-Tagged ROA Propagation 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: * MUST maintain the RPKI validation table with the risk metadata. * SHOULD apply local routing policy to automatically lower the Local_Pref of BGP routes matching the Risk-Tagged ROA. * MAY tag matching routes with a local administrative community for logging and inspection purposes. 4.4. Scheme 4: Inter-Router BGP Risk Attribute Propagation 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. Geng, et al. Expires 24 March 2027 [Page 5] Internet-Draft Dynamic Risk Indication & Propagation September 2026 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: * Reduce the Local_Pref of the indicated route. * Optionally propagate the risk signal to internal peers (iBGP) while stripping or filtering the attribute at eBGP boundaries according to local policy trust agreements. 5. Protocol Extensions 5.1. RTR Protocol Extensions (RTR Risk PDU) 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. BGP Routing Risk Extended Community 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 Geng, et al. Expires 24 March 2027 [Page 6] Internet-Draft Dynamic Risk Indication & Propagation September 2026 - Value: 2-octet Risk Sub-code, 4-octet Target AS/Peer ID. 6. Security Considerations 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. 7. IANA Considerations IANA is requested to allocate: 1. Two new PDU Types in the "RTR Protocol PDU Types" registry (0x0B, 0x0C). 2. 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: 8. Acknowledgements The authors would like to thank the IETF SIDROPS Working Group members for their valuable feedback and discussion. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Geng, et al. Expires 24 March 2027 [Page 7] Internet-Draft Dynamic Risk Indication & Propagation September 2026 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . 9.2. Informative 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, . Authors' Addresses Nan Geng Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: gengnan@huawei.com Longfei Dai Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: larry.dai@huawei.com Haibo Wang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Geng, et al. Expires 24 March 2027 [Page 8] Internet-Draft Dynamic Risk Indication & Propagation September 2026 Beijing 100095 China Email: rainsword.wang@huawei.com Shunwan Zhuang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Geng, et al. Expires 24 March 2027 [Page 9]