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

[Douglas Fischer <fischerdouglas () gmail com>]

In this case, in my opinion, I saw as the best scenario the FlowSpec Rules
being announced from ASN-Customer to ASN-Flowspec-Enforcer
- Not on a BGP Border of ASN-Flowspec-Enforcer.
- But on a Central RR-Cluster of ASN-Flowspec-Enforcer.


Em qua., 3 de fev. de 2021 às 07:36, Peter F. de Boer <
peterf.deboer () hotmail com> escreveu:

> In between the FS-Enforcer and the network there should be an arbiter that
> is able to report, analyse, approve, ignore or rollback rules that are
> being pushed. Not sure if this already exsists.
>
> Verzonden vanuit Outlook <http://aka.ms/weboutlook>
> ------------------------------
> *Van:* NANOG <nanog-bounces+peterf.deboer=hotmail.com () nanog org> namens
> Douglas Fischer <fischerdouglas () gmail com>
> *Verzonden:* woensdag 3 februari 2021 10:59
> *Aan:* Hank Nussbacher <hank () interall co il>
> *CC:* NANOG <nanog () nanog org>
> *Onderwerp:* Re: RTBH and Flowspec Measurements - Stop guessing when the
> attack will over
>
> Yep...
> But I remember the first concept of security:
> There is no real security on a single layer.
>
> So, considering That, FlowSpec should never be accepted directly by the
> FlowSpec-Enforcer-Box.
> It should be announced to another box, running other software than that
> one on the Perimeter, and filtering and refiltering should be done on both
> layers.
>
>
> Em qua., 3 de fev. de 2021 às 02:43, Hank Nussbacher <hank () interall co il>
> escreveu:
>
> 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.
>
>
> Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher <beecher () beecher cc>
> <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>
> 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> escreveu:
>
>
>
> On Feb 2, 2021, at 00:34, Douglas Fischer <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>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação


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