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