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

[Tom Beecher <beecher () beecher cc>]

> - 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.


There have been a great many things predicated on "if someone does it
properly".  While that is a noble goal, reality tells us that more commonly
people WON'T do it properly, so designing for that eventual certainty, to
me, is more important.

To your second point, I think it's a reasonable question to say if an
operator doesn't have requisite skills, expertise, attention+devotion to
run a thing, should they be running that thing in the first place?

On Tue, Feb 2, 2021 at 12:08 PM Douglas Fischer <fischerdouglas () gmail com>
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.
>
>
> 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>
> > 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