Hi,

On Fri, 29 Oct 2021 at 00:48, Amir Herzberg <amir.lists@gmail.com> wrote:
Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), we need access to historical data of blacklisted prefixes (due to spam, DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we already have). 

I read your paper. I note "ROV provides disappointing security benefits". I think we all know that ROV provides very little in the way of security from deliberate hijack without the protection of BGPsec as you later point out in your paper. 

What you seem to have failed to understand is that most traffic hijacks on the internet are not malicious in nature, they are "fat finger" incidents where someone has accidentally announced something they did not intend to, either because of faulty software (the infamous "BGP optimizer") or someone leaking internal "blocks" such as the Pakistan/YouTube incident -- certifying the origin of a prefix allows you to mitigate most of this as the origin AS will change. Anyone seen deliberately causing hijacks is likely to be depeered very quickly -- commercial pressure rather than technical.

Likewise, the core purpose of ROV is not to secure the entire address space. It is (as I understand it) to prevent *your* address space from being stolen, and to prevent your network from being affected by false advertisements. The superprefix attacks you mention are pretty much theoretical only at this time, because of the maximum prefix length attribute and the nature of peering in that networks either tend to be adjacent (therefore very low AS Path) or via transit (and most transit providers deploy ROV validation). It's true that traffic could be re-routed if the longer prefixes are not advertised to all parties, but that would also come under the AS Path length case.

Hijacking a prefix is not useful unless you can do something with it, either to hand out to customers (in which case, the prefix is going to be sufficiently ignored around the internet that it's not practically useful) or to engage in denial of service activities in which case there are far easier measures to use.
 
Any help would be appreciated. I'm not sure the list would be interested so I recommend you respond to me privately; if there are useful responses, I could post a summary to the list after few days (of collecting responses, if any). 

I would strongly encourage engaging with the IETF (https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more likely to be able to point you in the right direction.

Matthew Walster