BGP route hijack by AS10990

Mark Tinka mark.tinka at seacom.com
Mon Aug 3 14:55:01 UTC 2020



On 3/Aug/20 14:57, Tom Beecher wrote:

> Agreed. 
>
> However, every time we go on this Righteous Indignation of Should Do
> crusade, it would serve us well to stop and remember that in every one
> of our jobs, at many points in our careers, we have been faced with a
> situation where something we SHOULD do ends up being deferred for
> something we MUST to do. It is a universal truth that there will never
> enough time and resources to complete both, especially not in our
> current business environment that the only thing that matters is the
> numbers for the next quarter. Sometimes as engineers we have to make
> choices,  sometimes choices are imposed on us by pointy hairs. 
>
> Telia made a mistake. They owned it and will endeavor to do better.
> What more can be asked?

I think we've now gone past Telia's mistake and are considering what we
can all do as BGP actors to prevent this particular issue from making a
reprise.

Agreed, we all have bits we need to prioritize our time on. But the BGP
requires concerted effort of all actors on the Internet. How an operator
in Omsk works with BGP has a potentially direct impact on another
operator in Ketchikan. So whether I choose to spend more time on
attending conferences vs. upgrading my core network, neither of those
has an impact on the BGP. But if I'm going to not take BGP filtering as
seriously as I should, the engineer, their employer and customer,
sitting all the way in Yangon, could feel that.

The devices we use, nowadays, are only as useful as their connectedness.
No connectivity, and they're just bricks. Particularly in these
Coronavirus times, the Internet is what is keeping economies alive, and
folk employed. So rather than go back to the old days of, "We are busy,
it is what it is", let's figure out how to make it better. We don't have
to fix all of the Internet's governance issues this century - let's just
start with making this "BGP optimizer danger" fix + "all operators
should filter more deliberately" a reality.

Mark.




More information about the NANOG mailing list