Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, Juniper, etc... about how they can possibly allow every day screw ups to happen, but the same options like the NO_EXPORT community are available for the engineer to use? One solution would be to implement "BGP Group/Session Profiles" (ISP/RTBH/DDOS Filtering/Route Optimizers/etc) or a "BGP Session Wizard" (ask the operator questions about their intentions), then automatically generate import and export policies based on known accepted practices.
You seem to be implying that nobody has ever given feedback to a vendor about their BGP implementation. That's incredibly far from the truth. Default parameters on many NOS have been changed over the years to be safer for 2AM compliance, or for operators with lesser experience. It's correct that someone with any of those BGP implementations can make configuration errors. The difference is those configuration errors are LESS LIKELY to cause widespread disruption in the DFZ. I think back to many years ago at the start of my career, and the first time I configured BGP on a router with 2 upstreams. In an amazing rookie move, I created config which I did not apply, reannouncing everything from 3356 to 1239 via myself, and vice versa. While embracing, only a very small amount of traffic ( <10Mbps ) and prefixes were impacted, since BGP worked as designed, and the longer AS PATH I created was less desirable for almost everyone. IF you are going to create more specific announcements, be it with a BGP "optimizer" , or with other BGP implementations, the SAFEST method to prevent unintended consequences would be to add guardrails, like NO_EXPORT. It's just a best practice. When you can make those good best practices a default behavior? Even better! There is no downside to Nocton making NO_EXPORT the default behavior, only upside to the stability of the internet at large. On Sat, Aug 1, 2020 at 4:31 PM Ryan Hamel <ryan@rkhtech.org> wrote:
Job,
I disagree on the fact that it is not fair to the BGP implementation ecosystem, to enforce a single piece of software to activate the no-export community by default, due to ignorance from the engineer(s) implementing the solution. It should be common sense that certain routes that should be advertised beyond the local AS, just like RFC1918 routes, and more. Also, wasn't it you that said Cisco routers had a bug in ignoring NO_EXPORT? Would you go on a rant with Cisco, even if Noction add that enabled checkbox by default?
Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, Juniper, etc... about how they can possibly allow every day screw ups to happen, but the same options like the NO_EXPORT community are available for the engineer to use? One solution would be to implement "BGP Group/Session Profiles" (ISP/RTBH/DDOS Filtering/Route Optimizers/etc) or a "BGP Session Wizard" (ask the operator questions about their intentions), then automatically generate import and export policies based on known accepted practices.
Another solution could be having the BGP daemon disclose the make, model family, and exact model of hardware it is running on, to BGP peers, and add more knobs into policy creation to match said values, and take action appropriately. That would be useful in getting around vendor specific issues, as well as belt & suspenders protection.
Ryan On Aug 1 2020, at 9:58 am, Job Snijders <job@instituut.net> wrote:
On Sat, Aug 01, 2020 at 06:50:55AM -0700, Ca By wrote:
I am not normally supporting a heavy hand in regulation, but i think it is fair to say Noction and similar BGP optimizers are unsafe at any speed and the FTC or similar should ban them in the USA. They harm consumers and are a risk to national security / critical infrastructure
Noction and similar could have set basic defaults (no-export, only create /25 bogus routes to limit scope), but they have been clear that their greed to suck up traffic does not benefit from these defaults and they wont do it.
Following a large scale BGP incident in March 2015, noction made it possible to optionally set the well-known NO_EXPORT community on route advertisements originated by IRP instances.
"In order to further reduce the likelihood of these problems occurring in the future, we will be adding a feature within Noction IRP to give an option to tag all the more specific prefixes that it generates with the BGP NO_EXPORT community. This will not be enabled by default [snip]" https://www.noction.com/blog/route-optimizers Mar 27, 2015
Due to NO_EXPORT not being set in the default configuration, there are probably if not certainly many unsuspecting network engineers who end up deploying this software - without ever even considering - to change that one setting in the configuration.
Fast forward a few years and a few incidents, on the topic of default settings, following the Cloudflare/DQE/Verizon incident:
"We do have no export community support and have done for many years. The use of more specifics is also optional. Neither replaces the need for filters." https://twitter.com/noction/status/1143177562191011840 Jun 24, 2019
Community members responded:
"Noction have been facilitating Internet outages for years and years and the best thing they can say in response is that it is technically possible to use their product responsibly, they just don't ship it that way." https://twitter.com/PowerDNS_Bert/status/1143252745257979905 June 24, 2019
Last year Noction stated:
"Nobody found this leak pleasant." https://www.noction.com/news/incident-response June 26, 2019
Sentiment we all can agree with, change is needed!
As far as I know, Noction IRP is the ONLY commercially available off-the-shelf BGP route manipulation software which - as default - does NOT set the BGP well-known NO_EXPORT community on the product's route advertisements. This is a product design decision which causes collateral damage.
I would like to urge Noction to reconsider their position. Seek to migrate the existing users to use NO_EXPORT, and release a new version of the IRP software which sets NO_EXPORT BY DEFAULT on all generated routes.
Kind regards,
Job