Community discussions

MikroTik App
 
User avatar
Bergante
Member Candidate
Member Candidate
Topic Author
Posts: 140
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: 382
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: 140
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: 126
Joined: Tue Dec 11, 2012 4:56 am

Re: Feature request: BGP flowspec (RFC5575)

Mon Apr 20, 2015 5:07 pm

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

Re: Feature request: BGP flowspec (RFC5575)

Wed Jul 08, 2015 6:37 pm

want!
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1189
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: Feature request: BGP flowspec (RFC5575)

Thu Jul 09, 2015 2:25 am

Very slick +2!
Global - MikroTik Support & Consulting - English | Francais | Español | Portuguese +1 855-645-7684
https://iparchitechs.com/services/mikro ... l-support/ mikrotiksupport@iparchitechs.com
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 6043
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: 759
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.
-----
Mike Hammett

The Brothers WISP
 
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1870
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
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.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1189
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
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.
Global - MikroTik Support & Consulting - English | Francais | Español | Portuguese +1 855-645-7684
https://iparchitechs.com/services/mikro ... l-support/ mikrotiksupport@iparchitechs.com
 
Zorro
Long time Member
Long time Member
Posts: 676
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
IPANetEngineer
Trainer
Trainer
Posts: 1189
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
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/
Global - MikroTik Support & Consulting - English | Francais | Español | Portuguese +1 855-645-7684
https://iparchitechs.com/services/mikro ... l-support/ mikrotiksupport@iparchitechs.com
 
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: 759
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
-----
Mike Hammett

The Brothers WISP
 
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: 249
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 Veteran
Forum Veteran
Posts: 987
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: 249
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: 759
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.
-----
Mike Hammett

The Brothers WISP
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1870
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
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 ?
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
marrold
Member
Member
Posts: 417
Joined: Wed Sep 04, 2013 10:45 am

Re: Feature request: BGP flowspec (RFC5575)

Mon Dec 11, 2017 2:55 pm

+1 8)
I'm a SIP / VoIP engineer. Feel free to ask questions...
 
User avatar
YourWordIsTruth
just joined
Posts: 12
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
Frequent Visitor
Frequent Visitor
Posts: 52
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
Frequent Visitor
Frequent Visitor
Posts: 52
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: 636
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.

Who is online

Users browsing this forum: No registered users and 10 guests