Matthew Petach via NANOG wrote on 06/10/2025 22:23:
While this is an interesting demonstration of something we've all had a gut-level understanding probably takes place all the time due to inconsistent policies and unintentional overlooking of implementation details between peers, there are simpler ways to attack the DFZ core with more devastating impact.
more to the point, the moment you implement both filtering and propagation of subnets in a routing protocol which allows next-hop resolution, you can no longer deterministically defend against this entire class of threats. This is well known, e.g. connecting up a GRE VPN and inserting the NH of the endpoint into the tunnel. Or being careless with prefix redistribution between routing protocols and finding out that it's very easy to shoot yourself in the foot. Hopefully most network engineers have done this accidentally in their lives so that they learn to be aware of it as something that can happen. Obviously the singe marks on my fingers are from ... other things and definitely none of the above (looks at floor awkwardly). Anyway, the principle of all these things is the same: oscillatory invalidation of the next-hop ip address.
The amount of sleep I'd be losing worrying about this is negligible.
Indeed. On a separate issue, it's frustrating when people see the need to brand their discoveries with breathless names and often (not in this case) cutesy logos. What makes a vulnerability relevant is the product of its exploitability and its impact. I'd rate this one as being worth having router high-CPU triggers on the NMS and possibly churn counters, but not much more. Nick