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 From: NANOG Email List <nanog-bounces@nanog.org> on behalf of Colton Conor <colton.conor@gmail.com> Date: Thursday, April 23, 2020 at 9:15 AM To: NANOG list <nanog@nanog.org> Subject: FlowSpec 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. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
On 2020-04-23 18:13, Colton Conor wrote:
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. RETN considered Tier-2? They offer it, but it is more expensive than
On 2020-04-23 18:13, Colton Conor wrote:
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.
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/
On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:
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. 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. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
On 2020-04-23 19:12, Roland Dobbins wrote:
On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:
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 https://dyn.com/blog/longer-is-not-better/ 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. -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Denys Fedoryshchenko Sent: 23 April 2020 16:58 To: Colton Conor <colton.conor@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: [EXTERNAL] Re: FlowSpec On 2020-04-23 18:13, Colton Conor wrote:
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.
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://urldefense.com/v3/__https://blog.cloudflare.com/todays-outage-post-m... This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.
participants (5)
-
Colton Conor -
Compton, Rich A -
Denys Fedoryshchenko -
Nikos Leontsinis -
Roland Dobbins