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.deb...@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....@nanog.org> namens > Douglas Fischer <fischerdoug...@gmail.com> > *Verzonden:* woensdag 3 februari 2021 10:59 > *Aan:* Hank Nussbacher <h...@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 <h...@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 <beec...@beecher.cc> > <beec...@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 <fischerdoug...@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.dobb...@netscout.com> escreveu: > > > > On Feb 2, 2021, at 00:34, Douglas Fischer <fischerdoug...@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.dobb...@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