nanog mailing list archives

Re: Need for historical prefix blacklist (`rogue' prefixes) information


From: Matthew Walster <matthew () walster org>
Date: Fri, 29 Oct 2021 13:13:04 +0100

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

Current thread: