Community discussions

MikroTik App
 
User avatar
Bergante
Member Candidate
Member Candidate
Topic Author
Posts: 144
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Feature request: BGP flowspec (RFC5575)

Tue Nov 05, 2013 2:37 pm

Are you planning to implement this?

For unfamiliar readers, roughly speaking, it uses BGP to distribute filter specifications. It's very useful in DDoS attacks, allowing you to send "firewall rules" (matching on source and destination addresses, protocols, ports, etc) to your BGP peers/transits, so that they can discard or limit hostile traffic.

The best, no need to pester their NOC.

So far I think that only Juniper supports it, but Cisco has announced that they are working on it.

Definitely it doesn't look that hard to implement, the spec is quite clean.
 
eflanery
Member
Member
Posts: 376
Joined: Fri May 28, 2004 10:11 pm
Location: Moscow, ID
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Tue Nov 05, 2013 7:21 pm

+1

This would be great.

Currently we do something similar, in a hackish and rudimentary way, with separate routing tables for src-drop and dst-drop firewalls, and scripts that parse them into firewall rules.

This would be _much_ better, and even inter-operable with other providers (if you can find one that supports it).

--Eric
 
User avatar
Bergante
Member Candidate
Member Candidate
Topic Author
Posts: 144
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: Feature request: BGP flowspec (RFC5575)

Wed Nov 06, 2013 11:00 am

Right now not many transit providers support it.

From the Mikrotik side, the priority would be to implement the BGP exchange, even if RouterOS doesn't have the mechanisms in place to actually apply the rules, but at least enabling the RouterOS to send BGP flowspec advertisements to the transit providers.
 
jmginer
Member Candidate
Member Candidate
Posts: 153
Joined: Tue Dec 11, 2012 4:56 am
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Mon Apr 20, 2015 5:07 pm

vote +1
 
User avatar
rekeds
just joined
Posts: 13
Joined: Fri Mar 14, 2014 10:45 pm

Re: Feature request: BGP flowspec (RFC5575)

Wed Jul 08, 2015 6:37 pm

want!
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Thu Jul 09, 2015 2:25 am

Very slick +2!
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Thu Jul 09, 2015 9:53 am

Thank yo for feature request however here are few points against implementing such specification:

- General argument used to support such new BGP features:
Since BGP is such a stable and widely deployed thing,
let's add all kind of random stuff to it.
Once you start adding stuff, BGP implementation ceases
to be simple, stable, and gets whole lot of new
failure modes. Quoting rfc:

"While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to already
deployed mechanisms."

But you still need to configure it on each BGP speaker.
Why not, under the hood, make it a separate protocol so
that bugs in this thing don't pull whole BGP under?

- BGP NLRI is meant to carry address prefixes, which, in the
case of VPNv6, are 8 bytes RD + 16 bytes IPv6.
Data structures that handle such short ( <= 24 bytes)
prefixes well are generally not suited for storing
arbitrary length (into kilobytes) NLRI this RFC proposes to use.

The SANE way would have been to use NLRI as a short ID,
and keep flow matchers in the attributes. No reason in RFC is
given for their choice.

- If BGP speaker that redistributes flowspec gets DOSed,
flowspecs are removed from BGP peers. RFC does not
explain how this case is handled.

- This thing needs a way for administrator to monitor/limit
the amount of distributed info. You cannot use existing
tools for this thing.
 
unixman
just joined
Posts: 2
Joined: Mon Dec 30, 2013 7:43 pm

Re: Feature request: BGP flowspec (RFC5575)

Sat Oct 17, 2015 11:14 am

Thank yo for feature request however here are few points against implementing such specification:

- General argument used to support such new BGP features:
Since BGP is such a stable and widely deployed thing,
let's add all kind of random stuff to it.
Once you start adding stuff, BGP implementation ceases
to be simple, stable, and gets whole lot of new
failure modes. Quoting rfc:

"While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to already
deployed mechanisms."

But you still need to configure it on each BGP speaker.
Why not, under the hood, make it a separate protocol so
that bugs in this thing don't pull whole BGP under?

- BGP NLRI is meant to carry address prefixes, which, in the
case of VPNv6, are 8 bytes RD + 16 bytes IPv6.
Data structures that handle such short ( <= 24 bytes)
prefixes well are generally not suited for storing
arbitrary length (into kilobytes) NLRI this RFC proposes to use.

The SANE way would have been to use NLRI as a short ID,
and keep flow matchers in the attributes. No reason in RFC is
given for their choice.

- If BGP speaker that redistributes flowspec gets DOSed,
flowspecs are removed from BGP peers. RFC does not
explain how this case is handled.

- This thing needs a way for administrator to monitor/limit
the amount of distributed info. You cannot use existing
tools for this thing.
+1
Juniper does it since 7.3, and there are no good alternatives to prevent DDoS traffic. Cloudflare uses it, a lot of people uses it, if you want to give some sense to your "high end" devices you should think about this seriously.
 
User avatar
Hammy
Forum Veteran
Forum Veteran
Posts: 776
Joined: Fri May 28, 2004 5:53 pm
Location: DeKalb, IL
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Tue Nov 17, 2015 7:38 pm

Thank yo for feature request however here are few points against implementing such specification:

- General argument used to support such new BGP features:
Since BGP is such a stable and widely deployed thing,
let's add all kind of random stuff to it.
Once you start adding stuff, BGP implementation ceases
to be simple, stable, and gets whole lot of new
failure modes. Quoting rfc:

"While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to already
deployed mechanisms."

But you still need to configure it on each BGP speaker.
Why not, under the hood, make it a separate protocol so
that bugs in this thing don't pull whole BGP under?

- BGP NLRI is meant to carry address prefixes, which, in the
case of VPNv6, are 8 bytes RD + 16 bytes IPv6.
Data structures that handle such short ( <= 24 bytes)
prefixes well are generally not suited for storing
arbitrary length (into kilobytes) NLRI this RFC proposes to use.

The SANE way would have been to use NLRI as a short ID,
and keep flow matchers in the attributes. No reason in RFC is
given for their choice.

- If BGP speaker that redistributes flowspec gets DOSed,
flowspecs are removed from BGP peers. RFC does not
explain how this case is handled.

- This thing needs a way for administrator to monitor/limit
the amount of distributed info. You cannot use existing
tools for this thing.
Regardless of your like or dislike for Flowspec, that's what the community is moving forward with, so you need to get on board or you get replaced.
 
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2096
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Fri Apr 22, 2016 11:34 am

I can understand both points of view here.

But for lack of a better solution BGP Flowspec is becoming the industry standard.

If Mikrotik disagree with the implementation or the method, they can propose their preferred method as an RFC to the IETF.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Fri Apr 22, 2016 5:21 pm

I agree with NZ and see both positions but I will say that nobody has added more baggage to BGP than Cisco, and yet it remains a relatively stable implementation of BGP despite the enormous amount of proprietary/RFC additions.

BGP is a natural choice to add functionality because it is essentially the foundation of all large scale networks in the world. As SDN becomes more a part of our world, BGP is being utilized as the underlay for many of the SDN deployments and will continue to be expanded.

In order to keep pace with evolving threats and attacks, we need the same tools as competing network vendors are developing.
 
Zorro
Long time Member
Long time Member
Posts: 675
Joined: Wed Apr 16, 2014 2:43 pm

Re: Feature request: BGP flowspec (RFC5575)

Tue Apr 26, 2016 12:59 am

more options are always better and "generally" always better to had "Standard" things over proprietary stuff, even if thats Cisco-stuff (or other 1st echelon brands -lobbied/used).
and generic, standardised netflow (rather than cisco fork)is way to go IMHO.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Wed May 25, 2016 10:16 pm

We have more and more customers asking for this and we have to put either Quagga or BIRD in as the edge router since MikroTik doesn't have this. I'd prefer to put in a CCR, but we won't be able to until this feature is implemented. The lack of this feature is going to affect sales of CCRs for markets that need DDoS mitigation integrated with BGP - and that market is growing rapidly in 2016.

Here is a great overview of BGP FlowSpec that just came out a week ago and they do a great job of explaining why it's being used so heavily now.

https://packetpushers.net/podcast/podca ... itigation/
 
smunaut
newbie
Posts: 26
Joined: Fri Jul 08, 2016 10:24 pm

Re: Feature request: BGP flowspec (RFC5575)

Wed Jul 13, 2016 11:05 am

+1

At least the ability to push flowspec out to peers. (i.e. no need to interpret and actually apply the rules locally).

I understand Mikrotik's opinion above, but at this point in the process it's just irrelevant, it's too late, it's been adopted and the only viable choice is to support it.
 
User avatar
Hammy
Forum Veteran
Forum Veteran
Posts: 776
Joined: Fri May 28, 2004 5:53 pm
Location: DeKalb, IL
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Fri Nov 04, 2016 1:32 pm

I looked at another DDoS mitigation platform... that requires BGP FlowSpec.

Another source of information on BGP FlowSpec: https://www.youtube.com/watch?v=XBM5lgiPXGc
 
ecaps
just joined
Posts: 6
Joined: Mon Sep 19, 2016 12:17 am

Re: Feature request: BGP flowspec (RFC5575)

Mon Jan 16, 2017 7:18 pm

+1 for flowspec.
meanwhile flowspec is industry standard..
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: Feature request: BGP flowspec (RFC5575)

Sun Jul 30, 2017 2:52 pm

+100 RFC's are set, others have it implemented other isp's and transits are providing it we need this to stay on the target with the industry.

First support for the new nlri to validate, accept and forward them.
Then ability to form rules and actually act and influence traffic flow. But that can come later much later if you need more time and ask me. The myriad of api and other features in MT makes it open to us to influence from outside but we need the equipment to accept and forward the new information...

Thats my 10 cents.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1139
Joined: Tue Oct 11, 2005 4:53 pm

Re: Feature request: BGP flowspec (RFC5575)

Thu Oct 12, 2017 2:11 pm

+1
This is a must have nowadays.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: Feature request: BGP flowspec (RFC5575)

Fri Oct 13, 2017 8:46 pm

+1 Big Transit providers in Sweden Doe's it.
 
User avatar
Hammy
Forum Veteran
Forum Veteran
Posts: 776
Joined: Fri May 28, 2004 5:53 pm
Location: DeKalb, IL
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Sat Oct 14, 2017 6:33 pm

It probably would require the new routing engine in v7, so whenever that happens is the earliest we can expect FlowSpec.

I still want it ASAP, though.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2096
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Sun Oct 15, 2017 12:39 am

It probably would require the new routing engine in v7, so whenever that happens is the earliest we can expect FlowSpec.

I still want it ASAP, though.
v7 is a myth :D

What is it, 5 years overdue now ?
 
marrold
Member
Member
Posts: 427
Joined: Wed Sep 04, 2013 10:45 am

Re: Feature request: BGP flowspec (RFC5575)

Mon Dec 11, 2017 2:55 pm

+1 8)
 
User avatar
YourWordIsTruth
just joined
Posts: 18
Joined: Mon Mar 04, 2013 5:50 pm

Re: Feature request: BGP flowspec (RFC5575)

Thu Feb 08, 2018 6:52 pm

+1 - This is something should be on at least the CCR otherwise I see no reason to place CCR's on Internet Edge.
 
mhugo
Member Candidate
Member Candidate
Posts: 179
Joined: Mon Sep 19, 2005 11:48 am

Re: Feature request: BGP flowspec (RFC5575)

Wed Sep 19, 2018 10:50 pm

We also need this - +1
 
mhugo
Member Candidate
Member Candidate
Posts: 179
Joined: Mon Sep 19, 2005 11:48 am

Re: Feature request: BGP flowspec (RFC5575)

Mon May 25, 2020 11:22 pm

Now that ROS7 is here although without BGP lets keep our fingers crossed for flowspec support.
 
doush
Long time Member
Long time Member
Posts: 665
Joined: Thu Jun 04, 2009 3:11 pm

Re: Feature request: BGP flowspec (RFC5575)

Mon Jun 01, 2020 5:11 pm

When traffic flow is active on a DDOSed CCR, it crashes. (Traffic flow consumes all the CPUs )
BGP Flowspec is needed but also we need a less CPU intensive traffic flow implementation as well to complete the stack.
 
buraglio
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Aug 10, 2015 5:59 pm
Location: +1 (217)
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Fri Aug 26, 2022 12:34 am

it's 2022, any update on this for ROS7? Happy to test, big +1 to adding this.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Tue Jul 18, 2023 12:15 am

As seen in the following link:
https://help.mikrotik.com/docs/display/ ... attributes RouterOS already has certain level of support to BGP Flow Spec.
MikrotikBGPFlowSpecSupport.png
But I guess that the BGP Flow Spec feature acting itself directly to the FIB/Firewall will take some time to be released.
Mostly because of the complexity of the validation of Flow Spec and how it depends on the context that is being used.
For example the use of Flow Spec in L2 filtering scenarios, or the complexity of unicast validation against FIB.

However, I believe that in the current scenario of RouterOS v7.11beta, with some flexibility from the MikroTik team, it may be possible to make implementations using scripts that would bring results remarkably close to what is desired.

For this I brought a suggestion that involves the addition of hooks as a routing filter action.
I kindly ask colleagues to look at this thread:
Suggestion: Hooks to Scripts on /routing/filter/rule actions - BGP Flowspec
For those who can bring constructive suggestions, these will be well received.
You do not have the required permissions to view the files attached to this post.
 
expo
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Tue Jan 27, 2009 7:57 am

Re: Feature request: BGP flowspec (RFC5575)

Sat Sep 09, 2023 1:47 pm

Bump

Who is online

Users browsing this forum: No registered users and 19 guests