Re: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

["Compton, Rich A" <Rich.Compton () charter com>]

Hi, here is a Flowspec best practices document that I helped write that will hopefully help folks from shooting 
themselves in the foot http://m3aawg.org/flowspec-BP.  As you stated, route policies can be applied to restrict what 
type of flowspec rules can or can’t be accepted.  For example, only allow a rule from the Flowspec controller if it 
specifies a /32 destination IP and is tagged with a particular community, reject all else.
Douglas, I think what you are looking for is DOTS: https://tools.ietf.org/html/rfc8811  DOTS has a data channel which 
allows the DOTS client and server to communicate telemetry about the attack.  The RFC is pretty new.  I don’t think 
that there are any companies that have implemented it yet.  Hopefully this protocol will be adopted by DDoS mitigation 
companies soon.

-Rich Compton

From: NANOG <nanog-bounces+rich.compton=charter.com () nanog org> on behalf of Douglas Fischer <fischerdouglas () gmail 
com>
Date: Tuesday, February 2, 2021 at 10:10 AM
To: Tom Beecher <beecher () beecher cc>
Cc: NANOG list <nanog () nanog org>
Subject: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking 
links, or following guidance.
Well... That is a point of view!
And I must respect that.

Against this position, there are several companies, including some tier 1, that sells this as an $extra$.

About the "Please break me at my earliest inconvenience." part:
I believe that the same type of prefix filtering that applies to Downstream-BGP-Routes applies to RTBH and Flowspec.
So, exactly as in common BGP Route-Filtering:
- If the network operator does it correctly, it should work correctly.
- If the network operator deals with that without the needed skills, expertise, attention+devotion, wrong things will 
come up.


But, this still does not helps to find a solution do an organization A that sends some flowspec our RTBH to 
organization B(presuming organization B will accept that),  and organization B do some reports of what is match with 
that flowspec or RTBH.

That, in my opinion, is the only way to stop guessing how long will an attack will last, and start to define the end of 
a flowspec/RTBH action based on real information related to that.
I want to close the feedback loop.


Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher <beecher () beecher cc> escreveu:
Personally, I would absolutely, positively, never ever under any circumstances provide access to a 3rd party company to 
push a FlowSpec rule or trigger RTBH on my networks. No way.  You would be handing over a nuclear trigger and saying 
"Please break me at my earliest inconvenience."

On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer <fischerdouglas () gmail com<mailto:fischerdouglas () gmail com>> wrote:
OK, but do you know any company the sells de Flowspec as a service, in the way that the Attack Identifications are not 
made by their equipment, just receiving de BGP-FlowSpec and applying that rules on that equipments... And even then 
give back to the customer some way to access those statistics?

I just know one or two that do that, and(sadly) they do it on fancy web reports or PDFs.
Without any chance of using that as structured data do feedback the anomaly detection tools to determine if already it 
is the time to remove that Flowsperc rule.

What I'm looking for is something like:
A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream Equipments saying "Heepend that, that, and 
that." Almost in real time.
B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream Equipment, restricted to the DST-Address that matches 
to the IP blocks that were involved to the Flowspec or RTBH that I Annouced to then.
C) Any other idea that does the job of gives me the visibility of what is happening with FlowSpec-rules, or RTBH on 
theyr network.


Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland <Roland.Dobbins () netscout com<mailto:Roland.Dobbins () netscout 
com>> escreveu:



On Feb 2, 2021, at 00:34, Douglas Fischer <fischerdouglas () gmail com<mailto:fischerdouglas () gmail com>> wrote:

Or even know if already there is a solution to that and I'm trying to invent the wheel.

Many flow telemetry export implementations on routers/layer3 switches report both passed & dropped traffic on a 
continuous basis for DDoS detection/classification/traceback.

It's also possible to combine the detection/classification/traceback & flowspec trigger functions.

[Full disclosure: I work for a vendor of such systems.]


--------------------------------------------

Roland Dobbins <roland.dobbins () netscout com<mailto:roland.dobbins () netscout com>>


--
Douglas Fernando Fischer
Engº de Controle e Automação


--
Douglas Fernando Fischer
Engº de Controle e Automação
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.