Ryan,

To continue with your analogy, this would be more similar to someone who has never driven before walking into a dealership and buying a new car to drive off the lot. Ultimately the responsibility is on the driver, but the dealership should have never sold them the car in the first place. Thus, it's reasonable to place some of the responsibility on the vendors who introduce this equipment into the wild without truly understanding (or worse, not caring) how easy they've made it for their users to cause havoc when most of the defaults are left untouched. 

Again, it's not like anyone consciously sets these optimizers to evil, they're just spontaneously dangerous when left misconfigured (which is apparently easy to do). These devices throw caution to the wind in the name of being easy to use.

Think of all the companies that set up AD servers with "corp.com" and how big of a security risk that is. Microsoft ended up taking action because of the potentially catastrophic implications,  but at least it only affected the companies that made poor choices. Now imagine those same individuals who threw security to the wind are sold one of these devices because it's a turnkey way to make their network faster; that's exactly what we see here and it's terrifying to think how many of those little route hijack timebombs are out there, just waiting to ruin your day, night, or vacation in the Bahamas.

-Matt

On Sat, Aug 1, 2020 at 6:12 PM Ca By <cb.list6@gmail.com> wrote:


On Sat, Aug 1, 2020 at 4:47 PM Ryan Hamel <ryan@rkhtech.org> wrote:
Matt,

Why are you blaming the ease of use on the vendor, for the operators lack of knowledge regarding BGP? That is like blaming a vehicle manufacturer for a person pressing the gas pedal in a car and not giving a toss about the rules of the road. The base foundation regarding the rules of the road mostly apply the same for driving a car, truck, bus, and semi/lorry truck. There is no excuse for ignorance just because the user interface is different (web browser vs. SSH client).

Vendors are responsible.  The FTC slammed D-Link for being insecure and they can slam Noction too



Asking people in Pintos to not get in accidents is not an option. 





Adding a take on this, there are kids born after 9/11, with IP allocations and ASNs experimenting in the DFZ right now. If they can make it work, and not cause harm to other members in this community, it clearly demonstrates a lack of knowledge, or honest human error (which will never go away).

Anything that can be used, can be misused. With that said, why shouldn't ALL BGP software implementations encourage best practice? They decided RPKI validation was a good thing.

Ryan
On Aug 1 2020, at 4:12 pm, Matt Erculiani <merculiani@gmail.com> wrote:
Ryan,

The reason Noction is being singled out here as opposed to other BGP speakers is that it inherently breaks several BGP protection mechanisms as a means to achieve its purpose. BGP was never intended to be "optimized", it was intended to be stable and scalable. While i'm sure there are hundreds of operators that use these optimizers without incident, they are a significant paint point for the rest of the internet.

They have created a platform that has the ease of use of a residential CPE, but with the consequences of misuse of any DFZ platform. This allows users who have little experience speaking BGP with the world to make these mistakes because they don't know any better, whereas the other platforms you mention require some knowledge to configure. It's not a perfect filter, but it does create a barrier for the inept. 

Since Noction has made it easy enough to configure their software so that anyone can do it, with or without experience on the DFZ, they have SOME responsibility to keep their software from accidentally breaking the internet. 

-Matt


On Sat, Aug 1, 2020 at 2:30 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]"
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."
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."
June 24, 2019

Last year Noction stated:

"Nobody found this leak pleasant."
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


--
Matt Erculiani
ERCUL-ARIN


--
Matt Erculiani
ERCUL-ARIN