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

Wed Feb 3 09:59:26 UTC 2021

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 at 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 at beecher.cc>
> <beecher at 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 at 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 at netscout.com> escreveu:
>>>
>>>>
>>>>
>>>> On Feb 2, 2021, at 00:34, Douglas Fischer <fischerdouglas at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210203/93bd09f2/attachment.html>