We regularly see poorly configured "optimizers" or networks hijacking our prefixes (originating /25's, /24 of /23's etc).
Thankfully, most of the time filters are in place to stop them leaking badly, but I agree, these are toxic. -Tom On Fri, Sep 1, 2017 at 6:06 AM, Job Snijders <j...@ntt.net> wrote: > 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/ >
