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.

+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

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.

vote +1

want!

Very slick +2!

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.

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.

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.

Want to know more about BGP FlowSpec?


https://www.nanog.org/sites/default/fil ... dio.10.pdf

https://www.nanog.org/sites/default/fil ... _63.16.pdf

https://conference.apnic.net/data/37/ap ... 312254.pdf

http://www.slideshare.net/sfouant/an-in ... -flow-spec

http://www.slideshare.net/Arbor_Network ... wspec-2015

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.

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.

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.

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/

+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.

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

+1 for flowspec.
meanwhile flowspec is industry standard..

+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.

+1
This is a must have nowadays.

+1 Big Transit providers in Sweden Doe's it.

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.

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

What is it, 5 years overdue now ?

+1

+1 - This is something should be on at least the CCR otherwise I see no reason to place CCR's on Internet Edge.

We also need this - +1

Now that ROS7 is here although without BGP lets keep our fingers crossed for flowspec support.

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.

it's 2022, any update on this for ROS7? Happy to test, big +1 to adding this.

As seen in the following link:
https://help.mikrotik.com/docs/display/ ... attributes RouterOS already has certain level of support to BGP Flow Spec. 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.

Bump