BGP Optimizers (Was: Validating possible BGP MITM attack)

Thu Aug 31 20:06:49 UTC 2017

Dear all,

disclaimer:

    [ The following is targetted at the context where a BGP optimizer
    generates BGP announcement that are ordinarily not seen in the
    Default-Free Zone. The OP indicated they announce a /23, and were
    unpleasantly surprised to see two unauthorized announcements for /24
    more-specifics pop up in their alerting system. No permission was
    granted to create and announce these more-specifics. The AS_PATH
    for those /24 announcements was entirely fabricated. Original thread
    https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ]

On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote:
> Presuming it was a route optimizer and the issue was ongoing, what
> would be the suggested course of action?

I strongly recommend to turn off those BGP optimizers, glue the ports
shut, burn the hardware, and salt the grounds on which the BGP optimizer
sales people walked.

It is extremely irresponsible behavior to use software that generates
_fake_ BGP more-specifics for the purpose of traffic engineering. You
simply cannot expect that those more-specifics will never escape into
the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see
software bugs related to NO_EXPORT, and community-squashing
configuration mistakes happen all the time.

Consider the following: if you leak your own internal more-specifics, at
least you are the legitimate destination. (You may suffer from
suboptimal routing, but it isn't guaranteed downtime.) However if you
generate fake more-specifics for prefixes belonging to OTHER
organisations, you essentially are complicit in BGP hijacking. If those
fake more-specifics accidentally leak into the DFZ, you are bringing
down the actual owner of such prefixes, and depriving people from access
to the Internet. Example case:
https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html

> reach out to those 2 AS owners and see if they could stop it? 

Yes, absolutely! And if everyone of the affected parties of this
localized hijack leak (or should we say 'victims') reaches out to the
wrongdoers, they contribute peer pressure to rectify the situation. Just
make sure you assign blame to the correct party. :)

> Or is it something I just have to live with as a traffic engineering
> solution they are using and mark the alerts as false positives?

No, this is not something we should just accept. The Default-Free Zone
is a shared resource. Anyone using "BGP optimizers" is not only risking
their own online presence, but also everyone else's. Using a BGP
optimizer is essentially trading a degree of risk to society for the
purpose of saving a few bucks or milliseconds. It is basically saying:
"The optimizer helps me, but may hurt others, and I am fine with that".

An analogy: We don't want transporters of radioactive material to cut
corners by using non-existant roads to bring the spent nuclear fuels
from A to B faster, nor do we want them to rely on non-robust shielding
that works "most of the time".

We share the BGP DFZ environment, 'BGP optimizers' are downright
pollution contributors.

Kind regards,

Job

ps. If you want to do BGP optimization: don't have the BGP optimizer
generate fake BGP announcements, but focus only on manipulating
non-transitive attributes (like LOCAL_PREF) on real announcements you
actually received from others. Or Perhaps BGP optimizers shouldn't even
talk BGP but rather push freshly generated TE-optimized routing-policy
to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come
to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate
real announcements)... there are ways to do this, without risk to others!

p.s. providing a publicly available BGP looking glasses will contribute
to proving your innocence in cases like these. Since in many cases the
AS_PATH is a complete fabrication, we need to manually check every AS in
the AS_PATH to see whether the AS carries the fake more-specific. A
public looking glass speeds up this fault-finding process. If you don't
want to host a webinterface yourself, please consider sending a BGP feed
to the Route Views Project or RIPE RIS, or for something queryable in a
real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/