[Sidrops] Enforcement mechanisms

[John Scudder <[e-mail]>]

Regarding Amir Herzberg's "collateral damage", slide 9 of his presentation:

https://www.ietf.org/proceedings/99/slides/slides-99-sidrops-rpki-deployment-status-challenges-and-the-learning-validator-01.pdf

It occurs to me the described damage only occurs if AS 3 uses "drop the route" as its enforcement mechanism. Another option would be to blackhole traffic to the "bad" prefix  (1.1.1/24 on the slide) if and only if no good alternate route to the prefix is available (as is the case in the example on slide 9).

This would still represent a successful attack but a different one -- denial of service to the victim instead of data stealing. Note that in the example on slide 9, since AS 2 doesn't care about ROAs at all, we only have the options of devil or deep blue sea in any case.

The main liability of this approach that I see is if it's not a real attack but rather a "wrong" ROA, with the usual "drop the route" approach there often will be no (or not severe) negative consequences to the affected party, if they're covered by a properly ROA'd supernet, so you can still get your yogurt, albeit maybe through a suboptimal path. OTOH with the approach I describe, they're sure to lose connectivity, no yogurt. But I think this is really an argument for getting rid of "wrong" ROAs, not for using weak enforcement. (If you're using weak enforcement because you're afraid of the consequences of strong enforcement, you might as well admit you don't want to do enforcement at all.)

You can decide for yourself if the cure is worse than the disease. But I believe it's possible to configure your router to do this today, if you feel like it.

--John

P. S. This probably can be related back to the prehistory of CIDR, for those who remember that. Is this the first time CIDR has come up in SIDR?