Do any of the large transit providers support FlowSpec to transit customers / other carriers, or is that not a thing since they want to sell DDoS protection services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), but I am not sure if FlowSpec is widely implemented. I see the large router manufacturers support it.
Hi Colton,
It is fairly common to use flowspec internally at an ISP for mitigation of DDoS attacks. eBGP flowspec is not very common though. I know of only a couple of ISPs that allow flowspec rules to be advertised by their customers. The biggest issue with this is that other providers are very hesitant to allow an external party to reach into their routers and modify the configuration (add a flowspec rule). I (with others at my company) had attempted to work on this to provide a validation mechanism that would be performed on the advertised rules before adding them to the router. We didn’t see much interest at that time on this. https://www.youtube.com/watch?v=rKEz8mXcC7o
From conversations I have had with a couple of large ISPs recently it seems like there is an increased interest in this topic.
Here is a document on flowspec best practices that I worked on for M3AAWG that may be of interest: https://www.m3aawg.org/sites/default/files/m3aawg-flowspec-bp-2019-02.pdf
-Rich
RETN considered Tier-2?
They offer it, but it is more expensive than
RETN
They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.
In general operators don't like flowspec, because it is not easy to implement it right,
there is bugs and most important its "eating" TCAM.
For example: https://blog.cloudflare.com/todays-outage-post-mortem-82515/
Its increasing popularity tens to belie this assertion.
Yes, you're right that avoiding overflowing the TCAM is very important. But as Rich notes, a growing number of operators are in fact using flowspec within their own networks, when it's appropriate.
Smart network operators tend to do quite a bit of lab testing, prototyping, PoCs, et. al. against the very specific combinations of platforms/linecards/ASICs/OSes/trains/revisions before generally deploying new features and functionality; this helps ameliorate many concerns.
Also, don't forget about S/RTBH. It's generally confined to within an operator's own span of administrative control for some of the same reasons as flowspec (not generally TCAM, per se, but concerns about giving Customer A the ability to interfere with Customer B's traffic, and the difficulty of implementing such constraints). It can be an option worth exploring, in many circumstances.
In general operators don't like flowspec
Its increasing popularity tens to belie this assertion.
Yes, you're right that avoiding overflowing the TCAM is very
important. But as Rich notes, a growing number of operators are in
fact using flowspec within their own networks, when it's appropriate.
One of operators told me why they dont provide flowspec anymore:
customers are installing rules by scripts, stacking them,
and not removing then when they dont need them anymore.
RETN solved that by limiting number of rules customer can install.
Smart network operators tend to do quite a bit of lab testing,
prototyping, PoCs, et. al. against the very specific combinations of
platforms/linecards/ASICs/OSes/trains/revisions before generally
deploying new features and functionality; this helps ameliorate many
concerns.
Definitely, and i know some hosting operators who provide Flowspec functionality
different way - over their own web interface/API. This way they can do unit tests,
and do additional verifications.
But if there is direct BGP, things like Domain Name System (DNS) | Oracle
might happen, if customer is using some exotic, "nightly-build" BGP implementation.
If you can impose a limit on the amount of flowspec rules the customer can send you (I assume you are the Service provider) where is the problem
with offering flowspec services? Seems more of a vendor challenge.
The tcam issue is relatively addressed with proper dimensioning (throw money to the problem)
and you have created a service revenue opportunity so it is a win win for both
customer, provider and the entire community.
We cannot go very far with blackholing as a community.