Dynamic Risk Indication and Propagation in BGP (DRIP)

Resource Public Key Infrastructure (RPKI) Route Origin Validation (ROV) 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: Associated Path Depreference based on local ROV anomaly detection. Router-to-RP feedback loop for updating local ROA risk tables. RP-to-Router propagation of risk-tagged ROA entries. Inter-domain and intra-domain BGP signaling of risk states via a new BGP Path Attribute or Extended Community.

RP (Relying Party): An RPKI cache validator that collects, validates, and maintains RPKI data. ROV (Route Origin Validation): The process defined in . 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.

When a router identifies a hijacked or invalid route using RPKI ROV (or other detection mechanisms such as ASPA 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 . 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: 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.

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

This document extends the RPKI-to-Router Protocol (RTR v1 ) 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:

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