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