On Sun, Oct 22, 2023 at 5:47 PM Job Snijders via NANOG <nanog@nanog.org> wrote: > > On Sun, 22 Oct 2023 at 17:42, Amir Herzberg <amir.li...@gmail.com> wrote: >> >> Bill, thanks! You explained the issue much better than me. Yes, the problem >> is that, in my example, the operator was allocated 1.2.4/22 but the >> attacker is announcing 1.2.0/20, which is larger than the allocation, so >> the operator cannot issue ROA for it (or covering it). Of course, the RIR >> _could_ do it (but I don't think they do, right?). So this `superprefix >> hijack' may succeed in spite of all the ROAs that the operator could publish. >> >> I'm not saying this is much of a concern, as I never heard of such attacks >> in the wild, but I guess it _could_ happen in the future. > > > > How is “success” measured here? > > The attacker won’t be drawing traffic towards itself destined for addresses > in the /22, because of LPM > https://en.wikipedia.org/wiki/Longest_prefix_match > > Attackers don’t hijack IP traffic by announcing less-specifics. It don’t work > that way.
Even for positive ROAs (not AS 0 ROAs), that depends on how much of a region's routers have full-routes or use partial routes. In Brazil there are still many Mikrotik devices being used by BGP-speaking networks that fumble on full-routes, and the offending announcement might not have a LPM to choose from. That might be yet more prevalent in routers connecting to IXPs, because even default-route networks would see those announcements without a LPM to follow. Rubens
