Rogue objects in routing databases

Mon Jan 27 20:56:17 UTC 2020

Hi Stephane, NANOG –

Do the math for all pertained prefixes in the pastes, those 3 prefixes were just examples I had at hand,
and the event is still of quite some significance. Albeit ROA-validating routers being an argument that
extenuates probabilities and the ensuing effect, deployment of such still lacks, hence my mention of
reaching levels of (random guess) 90% global visibility still, taken the attacker understands ROA.

It is certainly unlikely that networks that are known for rather puerile filtering, or lack of adequate filtering
to filter the networks, so ultimately they will inevitably still transpire in the global tables. An impression
emerges that commitment in resolving this incident lacks, apart from  the guys over at NTT which,
from what I gathered, suspended their IRR account temporarily to prevent further damage.

—
Cheers,
Florian Brandstetter
On 27. Jan 2020, 7:03 PM +0100, Stephane Bortzmeyer <bortzmeyer at nic.fr>, wrote:
> On Sat, Jan 25, 2020 at 12:06:51AM +0100,
> Florian Brandstetter <florianb at globalone.io> wrote
> a message of 53 lines which said:
>
> > Examples of affected networks are:
> >
> > 193.30.32.0/23
> > 45.129.92.0/23
> > 45.129.94.0/24
>
> Note that 193.30.32.0/23 has also a ROA (announces by 42198). So,
> announces by AS8100 would be RPKI-invalid.
>
> 45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being
> announced on sunday 26.
>
> 45.129.94.0/24 has a ROA and is normally announced.
>
> So, if AS8100 were to use its abnormal route objects , announces would
> still be refused by ROA-validating routers.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200127/4eaabe66/attachment.html>