Summary

  • draft-geng-sidrops-bgp-drip-00 proposes four ways to associate, feed back and propagate BGP risk, including a risk label that can coexist with a cryptographically valid ROA.
  • The draft is an individual version-00 proposal with no IETF endorsement or formal standing. Its real design question is how an observation becomes authority to alter routing preference beyond the route that triggered it.
  • Safe evaluation requires separate receipts for detection, association, transport, receiving policy, preference change, expiry, rollback and measured reachability.

The first DRIP draft begins from a familiar routing-security frustration. Route Origin Validation assesses whether an origin AS is authorised for a prefix, but an operator may believe that one invalid or hijacked announcement points to a wider compromise. Other routes from the same origin or peer can remain formally acceptable even when the operator distrusts the surrounding behaviour.

The proposal answers with four connected schemes. A router can first correlate the suspect route with routes sharing an origin AS, immediate neighbour or AS-path pattern and reduce their Local_Pref. It can then send feedback to an RPKI relying party over an extended RTR session. The relying party can place the report in an internal risk database and distribute a risk-tagged ROA. Finally, a router can signal risk to another router through a proposed transitive opaque BGP Extended Community.

That sequence is easy to describe as telemetry. It is more accurately a proposed authority chain.

The local observation may be narrow: one prefix, one path and one timestamp. The action can be broad: lower preference for associated prefixes, an origin or traffic received from a peer. A relying party is no longer only delivering validated origin data from RPKI. In the draft’s model it may also carry an operational judgment that changes how routers value otherwise valid routes. An adjacent router can receive the same signal and decide whether its import policy should honour it.

The most important sentence in the mechanism is therefore not that risk can travel. It is that a valid cryptographic signature and an elevated-risk label can exist at the same time. They answer different questions. A ROA can say that an AS is authorised to originate a prefix. A risk label can say that current operational intelligence makes the route less desirable. Conflating the two would allow a non-cryptographic assessment to appear as if it were a failure of the underlying authorisation.

Association creates the blast radius

The draft names three association rules: common origin AS, common immediate neighbour or peer, and a matching AS-path sequence pattern. Each is plausible as an investigative lead. None is self-proving.

One origin can serve unrelated customers. One peer can carry many independent networks. Similar AS paths can reflect normal topology rather than common control. A detector that is correct about the triggering route can still be wrong about the associated set. Once the result changes Local_Pref, the association rule is no longer an analytical convenience; it determines which legitimate routes bear the cost of the initial suspicion.

That cost depends on alternatives. Depreference is not the same as hard filtering, and the draft explicitly recommends a minimum Local_Pref floor. Yet a lower preference can still move traffic to a congested, expensive, poorly observed or policy-incompatible path. If no usable alternative exists, even a soft action can become effective loss of reachability. A decision record must therefore preserve not only the preference delta but the alternatives visible at the moment of action and the service result afterwards.

Feedback changes the role of the relying party

The proposed router-to-RP feedback includes a prefix, suspect origin or peer, related ROA identifier and reason code. The relying party is expected to verify local telemetry and may alter confidence or mark a ROA as elevated risk. That phrase leaves the hardest governance work unresolved.

Whose telemetry qualifies as local? Which routers are authorised to report? How does the relying party distinguish a compromised detector from a genuine incident? What evidence supports a confidence change? How long does the judgment remain live? Who can withdraw, appeal or override it?

Transport security does not answer those questions. SSH or TLS can protect an RTR session from tampering and still faithfully carry a bad judgment. Authentication proves who sent the signal, not that the sender’s association rule was sound. A useful implementation would need detector accreditation, signed reasoned observations, freshness limits, replay handling and an audit trail that links every redistributed label to the original evidence.

The proposed wire values are not allocations

The institutional state is unusually important here. Datatracker lists only version 00, labels the document an active individual Internet-Draft, gives it no RFC stream or intended RFC status, and states that it is not endorsed by the IETF and has no formal standing.

The draft proposes RTR PDU types 0x0B and 0x0C and depicts protocol version 2 in the Risk PDU layout. The current IANA registry already assigns PDU type 11 (0x0B) to ASPA for protocol version 2, while type 12 remains unassigned. The draft also leaves the BGP Routing Risk Extended Community sub-type to be determined by IANA; the current registry contains no such named allocation.

These facts do not mean the idea has been rejected. They mean the text is a proposal whose encoding, process and compatibility questions remain open. An operator should not build an assumption of standardisation or interoperability from the draft’s example values.

Evidence should travel farther than the label

The Lu Heng doctrine supplies a useful test: a record describes reality; it does not create it. A warning can be evidence without becoming authority. Applied to DRIP, a detector may record an anomaly, a relying party may store a risk assessment and a router may transport a tag. None of those acts automatically earns the right to suppress another operator’s route.

The receiving network must retain the decision. That requires more than a configurable import-policy switch. It requires a receipt linking detector identity, raw observation, validation result, association logic, confidence, authenticated transport, propagation scope, local rule, preference delta, available alternatives, affected services, expiry and measured outcome. Withdrawal and rollback must be first-class events, not informal cleanup after the alarm disappears.

The first DRIP draft is valuable because it exposes the gap between origin authorisation and operational suspicion. Its risk is that closing the gap with one propagated label could hide a sequence of very different decisions. The right design target is not a faster red flag. It is a reversible, attributable chain in which every actor can show what it observed, what it inferred and why it had authority to act.

Sources