|
On 02/02/2021 19:08, Douglas Fischer
wrote:
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.
You forgot to mention software bugs:
https://kb.juniper.net/InfoCenter/index?page=content&id=JSA11101&cat=SIRT_1&actp=LIST
Note what Juniper states:
Workaround:
There are no viable workarounds for this issue
-Hank
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.
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."
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.
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.]
--
Douglas Fernando Fischer
Engº de Controle e Automação
--
Douglas
Fernando Fischer
Engº
de Controle e Automação
|
