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

[Douglas Fischer <fischerdouglas () gmail com>]

Hey Rich!
I'm in love with this RFC...

It is not an easy one, so I did not understand it completely yet.
But It is almost what I was thinking...

Does anyone saw any docs about deploying it?
Any software that implements it?



Em ter., 2 de fev. de 2021 às 15:53, Compton, Rich A <
Rich.Compton () charter com> escreveu:

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


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