Flowspec Implementation on Cisco ASR

[Pascal Masha]

Hi Folks,

Has anyone implemented flowspec on Cisco ASR terminating PPPoE users.
Flowspec rules should apply to the addresses assigned to PPPoE customers.
If yes, kindly share configuration samples..


Regards

Paschal Masha

Re: Flowspec IPv6

[Eric Dugas via NANOG]

Turns out the apply-group isn't working for v6 rules.

ATAC made me replicate the same rule directly under routing-options and
inet6flow.0 appeared and I can see my rule populated now.

FYI I'm running vRR 20.4R1-S1.2

On Sun, May 23, 2021 at 4:55 AM Zbyněk Pospíchal 
wrote:

> Hi Eric,
>
> with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any.
>
> --
> S pozdravem/Best Regards,
> Zbyněk
>
>
>
> Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a):
> > Hello,
> >
> > I've been fiddling with JunOS to enable Flowspec IPv6. According to the
> > docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX
> > in the 20.x train. Everything commit just fine, I get the inetflow.0 for
> > IPv4 but inet6flow.0 is not appearing.
> >
> > I already have a JTAC case (now escalated to ATAC) but I am looking for
> > plan B.
> >
> > Has anyone implemented Flowspec v6? I was thinking about FRRouting but I
> > wanted to get some feedback from the community before spending more
> > hours into this.
> >
> > Thanks
> > Eric
>
>

Re: Flowspec IPv6

[Trond Hastad via NANOG]

Hi,

I just configured this a few days ago on a mx960 running 18.4R3.
This was traffic redirection into a routing-instances so i do not know 
if it matches your setup.

But i can confirm that it is working in my setup.

Regards
Trond




Hello,

I've been fiddling with JunOS to enable Flowspec IPv6. According to
the docs, it was implemented in 16.x. I've tried to set it up in vRR
and vMX in the 20.x train. Everything commit just fine, I get the
inetflow.0 for IPv4 but inet6flow.0 is not appearing.

I already have a JTAC case (now escalated to ATAC) but I am looking
for plan B.

Has anyone implemented Flowspec v6? I was thinking about FRRouting but
I wanted to get some feedback from the community before spending more
hours into this.

Thanks
Eric

Re: Flowspec IPv6

[Zbyněk Pospíchal]

Hi Eric,

with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any.

-- 
S pozdravem/Best Regards,
Zbyněk



Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a):
> Hello,
> 
> I've been fiddling with JunOS to enable Flowspec IPv6. According to the
> docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX
> in the 20.x train. Everything commit just fine, I get the inetflow.0 for
> IPv4 but inet6flow.0 is not appearing.
> 
> I already have a JTAC case (now escalated to ATAC) but I am looking for
> plan B.
> 
> Has anyone implemented Flowspec v6? I was thinking about FRRouting but I
> wanted to get some feedback from the community before spending more
> hours into this.
> 
> Thanks
> Eric

Flowspec IPv6

[Eric Dugas via NANOG]

Hello,

I've been fiddling with JunOS to enable Flowspec IPv6. According to the
docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX in
the 20.x train. Everything commit just fine, I get the inetflow.0 for IPv4
but inet6flow.0 is not appearing.

I already have a JTAC case (now escalated to ATAC) but I am looking for
plan B.

Has anyone implemented Flowspec v6? I was thinking about FRRouting but I
wanted to get some feedback from the community before spending more hours
into this.

Thanks
Eric

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

[Peter F. de Boer]

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  namens Douglas 
Fischer 
Verzonden: woensdag 3 februari 2021 10:59
Aan: Hank Nussbacher 
CC: NANOG 
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 
mailto: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 
<mailto: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 
mailto: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 
mailto:roland.dobb...@netscout.com>> escreveu:


On Feb 2, 2021, at 00:34, Douglas Fischer 
mailto: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 mailto: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

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

[Tom Beecher]

>
> Do I read it right that there is no workaround, but the solution is to
> upgrade to an updated version which include the fix?
>

"Upgrade to fixed code" is the most common solution for every vendor.

To answer 'are they still vulnerable', IF someone is running one of the
listed versions, AND they have flowspec enabled, there is exposure.

On Wed, Feb 3, 2021 at 5:32 AM Jean St-Laurent via NANOG 
wrote:

> Interesting,
>
>
>
> Do I read it right that there is no workaround, but the solution is to
> upgrade to an updated version which include the fix?
>
>
>
> The solution is just above the workaround. From the same page posted.
>
>
> https://kb.juniper.net/InfoCenter/index?page=content&id=JSA11101&cat=SIRT_1&actp=LIST
>
>
>
> *Solution:*
>
> The following software releases have been updated to resolve this specific
> issue:
>
> Junos OS: 15.1R7-S8, 15.1X49-D240, 17.3R3-S10, 17.4R2-S12, 17.4R3-S4,
> 18.1R3-S12, 18.2R2-S8, 18.2R3-S6, 18.3R3-S4, 18.4R1-S8, 18.4R2-S6,
> 18.4R3-S6, 19.1R2-S2, 19.1R3-S3, 19.2R3-S1, 19.3R2-S5, 19.3R3-S1,
> 19.4R1-S3, 19.4R2-S3, 19.4R3, 20.1R2, 20.2R1-S3, 20.2R2, 20.3R1-S1, 20.3R2,
> 20.4R1, and all subsequent releases.
>
> Junos OS Evolved: 20.3R1-S1-EVO, 20.3R2-EVO, 20.4R1-EVO, and all
> subsequent releases.
>
>
>
>
>
> It has a cvss score of 10.0 which is the highest.
>
>
>
> Is Juniper still vulnerable or not?
>
>
>
> Thanks
>
>
>
> [image: ddosTest me Security inc]
>
> Jean St-Laurent
>
> CISSP #634103
>
>
>
> ddosTest me security inc
>
> tel:  438 806-9800 <+14388069800>
>
> site:  https://ddostest.me
>
> email:  j...@ddostest.me
>
>
>
>
>
>
>
>
>
> *From:* NANOG  *On Behalf Of *Hank
> Nussbacher
> *Sent:* February 3, 2021 12:41 AM
> *To:* nanog@nanog.org
> *Subject:* Re: RTBH and Flowspec Measurements - Stop guessing when the
> attack will over
>
>
>
> 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 
>  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 
> 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 
> 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 
>
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>

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

[Dobbins, Roland]

On Feb 3, 2021, at 17:01, Douglas Fischer  wrote:

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.

This is how the inter-operator implementations of which I'm aware function, via 
a  policy broker.




Roland Dobbins 

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

[Douglas Fischer]

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  namens
> Douglas Fischer 
> *Verzonden:* woensdag 3 februari 2021 10:59
> *Aan:* Hank Nussbacher 
> *CC:* NANOG 
> *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 
> 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 
>  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 
> 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 
> 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
>

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

[Jean St-Laurent via NANOG]

Interesting,

 

Do I read it right that there is no workaround, but the solution is to upgrade 
to an updated version which include the fix?

 

The solution is just above the workaround. From the same page posted.

https://kb.juniper.net/InfoCenter/index?page=content 
<https://kb.juniper.net/InfoCenter/index?page=content&id=JSA11101&cat=SIRT_1&actp=LIST>
 &id=JSA11101&cat=SIRT_1&actp=LIST

 

Solution:

The following software releases have been updated to resolve this specific 
issue:

Junos OS: 15.1R7-S8, 15.1X49-D240, 17.3R3-S10, 17.4R2-S12, 17.4R3-S4, 
18.1R3-S12, 18.2R2-S8, 18.2R3-S6, 18.3R3-S4, 18.4R1-S8, 18.4R2-S6, 18.4R3-S6, 
19.1R2-S2, 19.1R3-S3, 19.2R3-S1, 19.3R2-S5, 19.3R3-S1, 19.4R1-S3, 19.4R2-S3, 
19.4R3, 20.1R2, 20.2R1-S3, 20.2R2, 20.3R1-S1, 20.3R2, 20.4R1, and all 
subsequent releases.

Junos OS Evolved: 20.3R1-S1-EVO, 20.3R2-EVO, 20.4R1-EVO, and all subsequent 
releases.

 

 

It has a cvss score of 10.0 which is the highest. 

 

Is Juniper still vulnerable or not?

 

Thanks

 



  
<https://www.engardesecurite.ca/wp-content/uploads/2018/11/main1-1-214x300.gif> 


Jean St-Laurent 

CISSP #634103


 

ddosTest me security inc


tel:438 806-9800 


site:   <https://ddostest.me/> https://ddostest.me 


email:   <mailto:j...@ddostest.me> j...@ddostest.me 

 

 

 

 

From: NANOG  On Behalf Of Hank 
Nussbacher
Sent: February 3, 2021 12:41 AM
To: nanog@nanog.org
Subject: Re: RTBH and Flowspec Measurements - Stop guessing when the attack 
will over

 

You forgot to mention software bugs:

https://kb.juniper.net/InfoCenter/index?page=content 
<https://kb.juniper.net/InfoCenter/index?page=content&id=JSA11101&cat=SIRT_1&actp=LIST>
 &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  <mailto: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 mailto: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 
mailto:roland.dobb...@netscout.com> > escreveu:

 





On Feb 2, 2021, at 00:34, Douglas Fischer mailto: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 mailto:roland.dobb...@netscout.com> >




 

-- 

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




 

-- 

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

 

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

[Douglas Fischer]

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

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

[Hank Nussbacher]

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

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

[Tom Beecher]

>
> - 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 
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 
> 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 
>> 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 
>>>> 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 
>>>>
>>>
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>>
>>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

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

[Douglas Fischer]

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.comp...@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  on
> behalf of Douglas Fischer 
> *Date: *Tuesday, February 2, 2021 at 10:10 AM
> *To: *Tom Beecher 
> *Cc: *NANOG list 
> *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 
> 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 
> 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 
> 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
> 

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

[Compton, Rich A]

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  on behalf of 
Douglas Fischer 
Date: Tuesday, February 2, 2021 at 10:10 AM
To: Tom Beecher 
Cc: NANOG list 
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  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 
mailto: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 
mailto:roland.dobb...@netscout.com>> escreveu:



On Feb 2, 2021, at 00:34, Douglas Fischer 
mailto: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 mailto:roland.dobb...@netscout.com>>


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


--
Douglas Fernando Fischer
Engº de Controle e Automação
E-MAIL CONFIDENTIALITY NOTICE: 
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 t

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

[Douglas Fischer]

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 
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 
> 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 
>>> 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 
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>

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

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

[Tom Beecher]

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 
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 
>> 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 
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

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

[Douglas Fischer]

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


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

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

[Dobbins, Roland]

On Feb 2, 2021, at 00:34, Douglas Fischer  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 

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

[Douglas Fischer]

I think most here know (way better than me) the concepts of DDoS, anomaly
detection, and reactions.

Some of the reactions that can be implemented to reduce the impact of an
attack are Remote-Triggered BlackHole and FlowSpec Filtering.

In theory, using FlowSpec would be possible to de source the trigger of
that FlowSpec announcement receives the measurements of the
Flowspec-Enforcer-Box the measurements of those rules.
But in fact, considering FlowSpec-Enforcement as-a-service, I've never seen
that happens between FlowSpec-RulesGenerator-Box and FlowSpec-Enforcer-Box
that are operated by different organizations.
(If some company does, please let me know.)


So, in practical actions, the FlowSpec-RulesGenerator-Box needs to play a
guessing game of how long will take until the attack ceases.
- First, send that FlowSpec Filtering for 3 minutes.
- After that initial timer expires and removing the FlowSpec Filtering,
measure the Flows of his own equipment.
- If the attack is still there, re-announce the FlowSpec Filter Rule for
more 15 minutes.
- Wait to expire again, if the attack is still there re-announce for more
30 minutes, and keep this on an eternal loop.

The same occurs with Remote-Triggered-Blackhole.
I need to remove it and feel it is still there.
And every time I do that, small partial outages occur at the destination
network.


Have you already imagined if those who implemented the RTBH or FlowSpec
could give you some feedback of how is the usage of that BH or FlowSpecDrop?

I really still don't know how to do this...
Or even know if already there is a solution to that and I'm trying to
invent the wheel.

What do you think about that?
Any Ideas?



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

Re: BGP FLowspec to Yang/Yaml ACL

[Tim Jackson]

Use ExaBGP to insert the routes? (https://github.com/Exa-Networks/exabgp)

This is some old Perl that generates the older ExaBGP 2.0 style entries,
but it uses template toolkit which means you can easily change the output
format:

https://paste.somuch.fail/?744af55b8bea1414#WlXYkcfATNRxpRcr4NGOtxw4cqzStbCpApxmIevRPDk=

There's a lot more you could do to make this even more flexible, you don't
need YANG or to modify any config, just build something that accepts what
you're after and sends it as flowspec routes from ExaBGP to the routers you
care about.

--
Tim

On Tue, Jun 16, 2020 at 1:46 PM Douglas Fischer 
wrote:

> We were looking for some way to implement BGP Flowspec Filtering(just the
> permit/deny basic) using L3 switches  in an automated way.
>
> Searching a bit we found https://github.com/ios-xr/bgpfs2acl
>
> Is almost what we are looking for!
> But is focused on Cisco devices.
>
> We even considered fork it to our specific vendor.
> But before reinventing the wheel, I decide to ask to colleagues if anybody
> knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.
>
> If that exists, with Ansible/Netconf/RestConf(or some similar tool), it
> would be easy to delegate to Switchs doing the basic filtering that only
> More expensive Routers can do by now.
>
>
> P.S.: This Idea does not include(on the first moment) more
> complex features of Flowspec like Redirect ou Rate-Limt.
>
> Any suggestions or ideas?
>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

RE: BGP FLowspec to Yang/Yaml ACL

[adamv0025]

In order to use YANG you need a device that can speak NETCONF/RESTCONF and 
understands YANG.

There’s no such thing as “The YANG ACL” -there’s IETF YANG model for ACLs, 
there’s OpenConfig one, and your switch vendor might have another YANG model 
for representing ACLs. 

Whichever model provides sufficient coverage for your use case (i.e. can use 
the model to specify SRC/DST/MASK/DENY/ACCEPT) and is supported natively by 
your device (can send the ACL config in this format to the device at it knows 
what to do) is the right for you.   

 

If your devices do not support NETCONF/RESTCONF nor understand YANG you can 
still push the ACL changes via CLI scraping (Ansible)

 

Now in either case (netconf-yang/ansible), what you’re better off with is a 
tool that allows operator to enter the details of the ACL line to be added 
(details of the flow) and just take that input and insert it into the 
pre-defined/prepared template (yang/ansible template), then the script just 
prompts the resulting config to be pushed onto the device (devices).

 

 

adam

 

From: NANOG  On Behalf Of Douglas Fischer
Sent: Tuesday, June 16, 2020 7:40 PM
To: nanog@nanog.org
Subject: BGP FLowspec to Yang/Yaml ACL

 

We were looking for some way to implement BGP Flowspec Filtering(just the 
permit/deny basic) using L3 switches  in an automated way.

Searching a bit we found  <https://github.com/ios-xr/bgpfs2acl> 
https://github.com/ios-xr/bgpfs2acl

 

Is almost what we are looking for!
But is focused on Cisco devices.

We even considered fork it to our specific vendor.
But before reinventing the wheel, I decide to ask to colleagues if anybody 
knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.

 

If that exists, with Ansible/Netconf/RestConf(or some similar tool), it would 
be easy to delegate to Switchs doing the basic filtering that only More 
expensive Routers can do by now.


P.S.: This Idea does not include(on the first moment) more complex features of 
Flowspec like Redirect ou Rate-Limt.

 

Any suggestions or ideas? 

 

 

 

 

-- 

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

Re: BGP FLowspec to Yang/Yaml ACL

[Douglas Fischer]

Just a complementary demonstration of a cenário we this "bgpfs2acl" been
used.
https://youtu.be/8pNZJUHlRPk

Em ter., 16 de jun. de 2020 às 15:39, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:

> We were looking for some way to implement BGP Flowspec Filtering(just the
> permit/deny basic) using L3 switches  in an automated way.
>
> Searching a bit we found https://github.com/ios-xr/bgpfs2acl
>
> Is almost what we are looking for!
> But is focused on Cisco devices.
>
> We even considered fork it to our specific vendor.
> But before reinventing the wheel, I decide to ask to colleagues if anybody
> knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.
>
> If that exists, with Ansible/Netconf/RestConf(or some similar tool), it
> would be easy to delegate to Switchs doing the basic filtering that only
> More expensive Routers can do by now.
>
>
> P.S.: This Idea does not include(on the first moment) more
> complex features of Flowspec like Redirect ou Rate-Limt.
>
> Any suggestions or ideas?
>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


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

BGP FLowspec to Yang/Yaml ACL

[Douglas Fischer]

We were looking for some way to implement BGP Flowspec Filtering(just the
permit/deny basic) using L3 switches  in an automated way.

Searching a bit we found https://github.com/ios-xr/bgpfs2acl

Is almost what we are looking for!
But is focused on Cisco devices.

We even considered fork it to our specific vendor.
But before reinventing the wheel, I decide to ask to colleagues if anybody
knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.

If that exists, with Ansible/Netconf/RestConf(or some similar tool), it
would be easy to delegate to Switchs doing the basic filtering that only
More expensive Routers can do by now.


P.S.: This Idea does not include(on the first moment) more complex features
of Flowspec like Redirect ou Rate-Limt.

Any suggestions or ideas?




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

RE: [EXTERNAL] Re: FlowSpec

[Nikos Leontsinis]

If you can impose a limit on the amount of flowspec rules the customer can send 
you (I assume you are the Service provider) where is the problem
 with offering  flowspec services? Seems more of a vendor challenge.

The tcam issue is relatively addressed with proper dimensioning (throw money to 
the problem)
 and you have created a service revenue opportunity so it is a win win for both
 customer, provider and the entire community.
We cannot go very far with blackholing as a community.


-Original Message-
From: NANOG  On Behalf Of Denys Fedoryshchenko
Sent: 23 April 2020 16:58
To: Colton Conor 
Cc: NANOG 
Subject: [EXTERNAL] Re: FlowSpec

On 2020-04-23 18:13, Colton Conor wrote:
> Do any of the large transit providers support FlowSpec to transit
> customers / other carriers, or is that not a thing since they want to
> sell DDoS protection services? FlowSpec sounds much better than RTBH
> (remotely triggered blackhole), but I am not sure if  FlowSpec is
> widely implemented. I see the large router manufacturers support it.

RETN

They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.

In general operators don't like flowspec, because it is not easy to implement 
it right, there is bugs and most important its "eating" TCAM.
For example:
https://urldefense.com/v3/__https://blog.cloudflare.com/todays-outage-post-mortem-82515/__;!!PcPv50trKLWG!jJCV6iVdjh9kx3oiFfxOwO6BdJfkVq6eY8iqqerUChY1t8qUVWITa00EAx1J1zloDMvF1WX9$
This email is from Equinix (EMEA) B.V. or one of its associated companies in 
the territory from where this email has been sent. This email, and any files 
transmitted with it, contains information which is confidential, is solely for 
the use of the intended recipient and may be legally privileged. If you have 
received this email in error, please notify the sender and delete this email 
immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA 
Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 19:12, Roland Dobbins wrote:

On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:


In general operators don't like flowspec


Its increasing popularity tens to belie this assertion.

Yes, you're right that avoiding overflowing the TCAM is very
important.  But as Rich notes, a growing number of operators are in
fact using flowspec within their own networks, when it's appropriate.

One of operators told me why they dont provide flowspec anymore:
customers are installing rules by scripts, stacking them,
and not removing then when they dont need them anymore.
RETN solved that by limiting number of rules customer can install.



Smart network operators tend to do quite a bit of lab testing,
prototyping, PoCs, et. al. against the very specific combinations of
platforms/linecards/ASICs/OSes/trains/revisions before generally
deploying new features and functionality; this helps ameliorate many
concerns.
Definitely, and i know some hosting operators who provide Flowspec 
functionality
different way - over their own web interface/API. This way they can do 
unit tests,

and do additional verifications.

But if there is direct BGP, things like 
https://dyn.com/blog/longer-is-not-better/
might happen, if customer is using some exotic, "nightly-build" BGP 
implementation.

Re: FlowSpec

[Roland Dobbins]

On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:


In general operators don't like flowspec


Its increasing popularity tens to belie this assertion.

Yes, you're right that avoiding overflowing the TCAM is very important.  
But as Rich notes, a growing number of operators are in fact using 
flowspec within their own networks, when it's appropriate.


Smart network operators tend to do quite a bit of lab testing, 
prototyping, PoCs, et. al. against the very specific combinations of 
platforms/linecards/ASICs/OSes/trains/revisions before generally 
deploying new features and functionality; this helps ameliorate many 
concerns.


Also, don't forget about S/RTBH.  It's generally confined to within an 
operator's own span of administrative control for some of the same 
reasons as flowspec (not generally TCAM, per se, but concerns about 
giving Customer A the ability to interfere with Customer B's traffic, 
and the difficulty of implementing such constraints).  It can be an 
option worth exploring, in many circumstances.



Roland Dobbins 

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 18:13, Colton Conor wrote:

Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure if  FlowSpec is
widely implemented. I see the large router manufacturers support it.


RETN

They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.

In general operators don't like flowspec, because it is not easy to 
implement it right,

there is bugs and most important its "eating" TCAM.
For example: 
https://blog.cloudflare.com/todays-outage-post-mortem-82515/

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 18:13, Colton Conor wrote:

Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure if  FlowSpec is
widely implemented. I see the large router manufacturers support it.

RETN considered Tier-2?
They offer it, but it is more expensive than

Re: FlowSpec

[Compton, Rich A]

Hi Colton,
It is fairly common to use flowspec internally at an ISP for mitigation of DDoS 
attacks.  eBGP flowspec is not very common though.  I know of only a couple of 
ISPs that allow flowspec rules to be advertised by their customers.  The 
biggest issue with this is that other providers are very hesitant to allow an 
external party to reach into their routers and modify the configuration (add a 
flowspec rule).  I (with others at my company) had attempted to work on this to 
provide a validation mechanism that would be performed on the advertised rules 
before adding them to the router.  We didn’t see much interest at that time on 
this.  https://www.youtube.com/watch?v=rKEz8mXcC7o
From conversations I have had with a couple of large ISPs recently it seems 
like there is an increased interest in this topic.
Here is a document on flowspec best practices that I worked on for M3AAWG that 
may be of interest: 
https://www.m3aawg.org/sites/default/files/m3aawg-flowspec-bp-2019-02.pdf

-Rich

From: NANOG Email List  on behalf of Colton Conor 

Date: Thursday, April 23, 2020 at 9:15 AM
To: NANOG list 
Subject: FlowSpec

Do any of the large transit providers support FlowSpec to transit customers / 
other carriers, or is that not a thing since they want to sell DDoS protection 
services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), 
but I am not sure if  FlowSpec is widely implemented. I see the large router 
manufacturers support it.





E-MAIL CONFIDENTIALITY NOTICE: 
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.

FlowSpec

[Colton Conor]

Do any of the large transit providers support FlowSpec to transit customers
/ other carriers, or is that not a thing since they want to sell DDoS
protection services? FlowSpec sounds much better than RTBH (remotely
triggered blackhole), but I am not sure if  FlowSpec is widely implemented.
I see the large router manufacturers support it.

Any IP Transit provider currently offering BGP FlowSpec?

[Kurt Kraut]

Hello,


I'm looking for an IP Transit provider (in the Americas region preferrably)
that provides BGP FlowSpec capabilities. I've found some that accept
filtering rules at the IP Transit level but changes are done by support
ticket, which is subpar to me. I must have autonomy to change rules at will.

 Could anyone mention known providers publically? If you work for an IP
Transit provider, feel free to contact me privately/directly.


Best regards,


Kurt Kraut

Re: FlowSpec Support

[Mike Hammett]

I read that discussion (and several others going back about two or three years) 
before I posted this. 

As an occasional OP on here, I've noticed I get a lot of off-list responses so 
I obviously wouldn't have seen any of those from other people's threads. 

I didn't take that observation away from that thread, but maybe I'm dense. ;-) 
I know it was suggested that they wanted to bill for that sued capacity, but 
that was debunked. I know DDoS services were mentioned, but I didn't see a 
clear line drawn to that's why it isn't happening... nor confirmed. 

Also, what's big? Listed on the Baker's Dozen? Wide-spread POPs on six 
continents? Showing up on 50 IXPs? 1k IPv4 adjacencies? 

A medium sized network that does FlowSpec could be vastly more useful to you 
than a large network that doesn't. 





- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Josh Reynolds"  
To: "Mike Hammett"  
Cc: "NANOG"  
Sent: Saturday, May 28, 2016 5:41:38 PM 
Subject: Re: FlowSpec Support 


There was just a recent discussion about this. 
None of the big upstreams support it because they are all too busy selling 
their own DDoS mitigation services :) 
On May 28, 2016 5:38 PM, "Mike Hammett" < na...@ics-il.net > wrote: 


I know support (from customers) is limited among networks. I know it isn't on 
all hardware, but does appear to be on at least a couple platforms from the 
major router vendors. It is supported on an increasing number of DDoS 
appliances and software packages. 

What all networks support receiving BGP FlowSpec information from customers and 
acting upon it? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

Re: FlowSpec Support

[Josh Reynolds]

There was just a recent discussion about this.

None of the big upstreams support it because they are all too busy selling
their own DDoS mitigation services :)
On May 28, 2016 5:38 PM, "Mike Hammett"  wrote:

> I know support (from customers) is limited among networks. I know it isn't
> on all hardware, but does appear to be on at least a couple platforms from
> the major router vendors. It is supported on an increasing number of DDoS
> appliances and software packages.
>
> What all networks support receiving BGP FlowSpec information from
> customers and acting upon it?
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

FlowSpec Support

[Mike Hammett]

I know support (from customers) is limited among networks. I know it isn't on 
all hardware, but does appear to be on at least a couple platforms from the 
major router vendors. It is supported on an increasing number of DDoS 
appliances and software packages. 

What all networks support receiving BGP FlowSpec information from customers and 
acting upon it? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

Re: BGP FlowSpec

[Roland Dobbins]

On 3 May 2016, at 5:38, Martin Bacher wrote:


Let the packets come is not the message.


That was *precisely* the message which was spoken to me directly by a 
large regional CONUS ISP in mid-2003 or thereabouts.  I know this; I was 
there.


And it was the wrong message, as that particular ISP found out a couple 
of weeks later when their network was knocked flat and they lost 
customers because of it.  A bit of schadenfreude might not have been out 
of place, for the less-charitably inclined.


or remark and/or rate-limit the particular flows with nearly, of 
course not for the customer under attack, the same result.


This is almost always a Bad Idea, because the programmatically-generated 
attack traffic ends up 'crowding out' the legitimate traffic.  For some 
attacks which are obviously out-of-profile with regards to the attack 
targets, this isn't as much of a concern; some large network operators 
are doing this with regards to common UDP reflection/amplification 
traffic (but they're being careful about it).


And that still doesn't address the issue of high-volume traffic choking 
peering/transit links, of course.


But that does not imply that all upstream ISPs are filtering out 
attacks by default for customers which are not paying for that.


Nobody here has said that.  But some beneficiary collateral effects of 
this nature do show up, from time to time.


This is at least my interpretation from reading the various available 
DDoS reports and research papers.


You should probably be aware that you are likely conversing directly 
with the authors of/contributors to some of those very reports and 
research papers in this thread (depending on which reports and papers 
you mean), and that the people with whom you are interacting routinely 
mitigate DDoS attacks on the public Internet as part of their normal 
work routine - and have done so for many years.


For many of us, this is not a theoretical discussion; and it would 
probably be a good idea to keep in mind that our contributions to this 
thread aren't based upon reading various reports and research papers, 
but rather upon our actions which generate the data and experiential 
observations upon which such reports and research papers are based.


---
Roland Dobbins 

Re: BGP FlowSpec

[Martin Bacher]

> Am 03.05.2016 um 00:06 schrieb Roland Dobbins :
> 
> On 3 May 2016, at 4:51, jim deleskie wrote:
> 
>> I was going to avoid this thread because I've never been a huge fan of 
>> Flowspec for my own reasons.
> 
> Flowspec is an extremely useful tool, IMHO - not only for direct, 
> layer-4-granular mitigation leveraging linecard ASICs, but for more granular 
> and selective diversion into mitigation centers, as well.  And its value is 
> growing with increased platform support.  It isn't perfect (nothing is), and 
> operators must be aware of its performance/scalability envelope on a given 
> platform, but it's a great tool to have in the toolbox.
+1

> 
>> I can say I, nor any of my peers ( in any sense of that word) that I have 
>> known, have wanted to keep "bad " traffic on our networks so we can bill for 
>> it.
> 
> +1!
> 
> I ran into this situation precisely twice early in the 'oughts ("Let the 
> packets come!" was the quote which stood out in my mind); those espousing it 
> pretty quickly changed their tunes once their networks had been knocked flat 
> a couple of times.
Let the packets come is not the message. But an upstream ISP can either drop 
the traffic to reduce the impact on the own network and the customers which are 
not attacked directly or remark and/or rate-limit the particular flows with 
nearly, of course not for the customer under attack, the same result. And 
please don’t get me wrong. I am not a fan of implementing it that way. 

I also want to add something to keeping bad traffic: Well, nobody wants to keep 
bad traffic. But that does not imply that all upstream ISPs are filtering out 
attacks by default for customers which are not paying for that. This is at 
least my interpretation from reading the various available DDoS reports and 
research papers. 

> 
> ;>
> 
> ---
> Roland Dobbins 

Re: BGP FlowSpec

[Martin Bacher]

> Am 02.05.2016 um 23:51 schrieb jim deleskie :
> 
> I was going to avoid this thread because I've never been a huge fan of
> Flowspec for my own reasons. However having work on /been responsible for
> several "Tier 1 and 2" networks and DDoS mitigation services over the last
> 20 years,  I can say I, nor any of my peers ( in any sense of that word)
> that I have known, have wanted to keep "bad " traffic on our networks so
> we can bill for it.  Designing and running a large network is hard enough
> with planed growth, without having to manage unplanned spikes on links that
> can be  orders of magnitude larger then traffic that "normally" flows
> across it.
I was for sure not precise enough in my statement and should have left out the 
money part. Sorry for that. An ISP would of course protect its own 
infrastructure and other customers if the attack is large enough and always 
tries to keep the general impact as low as possible. But auto mitigation is 
usually only provided for customers which are paying for it. BGP-FS offers an 
easy way for automatic deployment of traffic remarking of attack traffic in 
order to keep the overall impact for the own network and other customers at a 
very low level.

> On top of that any given DDoS attack seldom last long enough to materially
> impact 95%ile billing, so carriers don't make anything from it, but have to
> do all the work of moving it around.
> 
> -jim
> 
> On Mon, May 2, 2016 at 6:38 PM, Roland Dobbins  wrote:
> 
>> On 2 May 2016, at 20:16, Martin Bacher wrote:
>> 
>> However, Tier 1s and most probably also some of the Tier 2s may not want
>>> to offer it to customers because they are loosing money if less traffic is
>>> sent downstream on IP-Transit links.
>>> 
>> 
>> I will go a step further than Danny's comments and state that this is
>> categorically and demonstrably untrue.
>> 
>> Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology)
>> operators on this list offer commercial DDoS mitigation services making use
>> of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand.
>> They need these capabilities in order to defend their own properties and
>> assets, and they are also offering them to end-customers who want and need
>> them.
>> 
>> In point of fact, it's becoming difficult to find one which *doesn't*
>> offer this type of service.
>> 
>> There were a couple of situations in the first half of the first decade of
>> this millennium where operators took this attitude.  But they changed their
>> tunes pretty rapidly once they themselves were impacted, and once they
>> started losing customers because they couldn't and wouldn't protect them.
>> 
>> And as Danny notes, these technologies are all tools in the toolbox.  NFV
>> and 'SDN' have tremendous potential to make it a lot easier to bring
>> mitigation resources to bear in a dynamic and optimal fashion within single
>> spans of administrative control; and there are standards-based efforts
>> underway to provide for a higher degree of automation, increased rapidity
>> of response, and interoperability in both inter- and intra-network DDoS
>> mitigation scenarios.
>> 
>> ---
>> Roland Dobbins 
>> 

Re: BGP FlowSpec

[Martin Bacher]

> Am 02.05.2016 um 23:38 schrieb Roland Dobbins :
> 
> On 2 May 2016, at 20:16, Martin Bacher wrote:
> 
>> However, Tier 1s and most probably also some of the Tier 2s may not want to 
>> offer it to customers because they are loosing money if less traffic is sent 
>> downstream on IP-Transit links.
> 
> I will go a step further than Danny's comments and state that this is 
> categorically and demonstrably untrue.
> 
> Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology) 
> operators on this list offer commercial DDoS mitigation services making use 
> of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand.  
> They need these capabilities in order to defend their own properties and 
> assets, and they are also offering them to end-customers who want and need 
> them.
> 
> In point of fact, it's becoming difficult to find one which *doesn't* offer 
> this type of service.
It was not meant to be a general statement that they are not offering anti DDoS 
services in whatever flavor. But you usually just get what you pay for. 
Furthermore, my statement was related to inter-AS BGP-FS and that providers may 
not offer it to customers but use in instead for traffic remarking to something 
like worse than best effort and still forwarding it to a customer under attack 
if he is not paying extra fees for DDoS mitigation. That does not mean that the 
ISP does not help on request or deploys countermeasures if its own 
infrastructure or other customers are suffering from that attack. But he may 
not perform any mitigation (except for the own protection) by default. 


> 
> There were a couple of situations in the first half of the first decade of 
> this millennium where operators took this attitude.  But they changed their 
> tunes pretty rapidly once they themselves were impacted, and once they 
> started losing customers because they couldn't and wouldn't protect them.
> 
> And as Danny notes, these technologies are all tools in the toolbox.  NFV and 
> 'SDN' have tremendous potential to make it a lot easier to bring mitigation 
> resources to bear in a dynamic and optimal fashion within single spans of 
> administrative control; and there are standards-based efforts underway to 
> provide for a higher degree of automation, increased rapidity of response, 
> and interoperability in both inter- and intra-network DDoS mitigation 
> scenarios.
Sounds nice. Looking forward to see that implemented on a large scale in 
inter-AS setups. But I am not sure if this will really happen. 

> 
> ---
> Roland Dobbins 

Re: BGP FlowSpec

[Roland Dobbins]

On 3 May 2016, at 4:51, jim deleskie wrote:

I was going to avoid this thread because I've never been a huge fan of 
Flowspec for my own reasons.


Flowspec is an extremely useful tool, IMHO - not only for direct, 
layer-4-granular mitigation leveraging linecard ASICs, but for more 
granular and selective diversion into mitigation centers, as well.  And 
its value is growing with increased platform support.  It isn't perfect 
(nothing is), and operators must be aware of its performance/scalability 
envelope on a given platform, but it's a great tool to have in the 
toolbox.


I can say I, nor any of my peers ( in any sense of that word) that I 
have known, have wanted to keep "bad " traffic on our networks so we 
can bill for it.


+1!

I ran into this situation precisely twice early in the 'oughts ("Let the 
packets come!" was the quote which stood out in my mind); those 
espousing it pretty quickly changed their tunes once their networks had 
been knocked flat a couple of times.


;>

---
Roland Dobbins 

Re: BGP FlowSpec

[jim deleskie]

I was going to avoid this thread because I've never been a huge fan of
Flowspec for my own reasons. However having work on /been responsible for
several "Tier 1 and 2" networks and DDoS mitigation services over the last
20 years,  I can say I, nor any of my peers ( in any sense of that word)
 that I have known, have wanted to keep "bad " traffic on our networks so
we can bill for it.  Designing and running a large network is hard enough
with planed growth, without having to manage unplanned spikes on links that
can be  orders of magnitude larger then traffic that "normally" flows
across it.

On top of that any given DDoS attack seldom last long enough to materially
impact 95%ile billing, so carriers don't make anything from it, but have to
do all the work of moving it around.

-jim

On Mon, May 2, 2016 at 6:38 PM, Roland Dobbins  wrote:

> On 2 May 2016, at 20:16, Martin Bacher wrote:
>
>  However, Tier 1s and most probably also some of the Tier 2s may not want
>> to offer it to customers because they are loosing money if less traffic is
>> sent downstream on IP-Transit links.
>>
>
> I will go a step further than Danny's comments and state that this is
> categorically and demonstrably untrue.
>
> Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology)
> operators on this list offer commercial DDoS mitigation services making use
> of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand.
> They need these capabilities in order to defend their own properties and
> assets, and they are also offering them to end-customers who want and need
> them.
>
> In point of fact, it's becoming difficult to find one which *doesn't*
> offer this type of service.
>
> There were a couple of situations in the first half of the first decade of
> this millennium where operators took this attitude.  But they changed their
> tunes pretty rapidly once they themselves were impacted, and once they
> started losing customers because they couldn't and wouldn't protect them.
>
> And as Danny notes, these technologies are all tools in the toolbox.  NFV
> and 'SDN' have tremendous potential to make it a lot easier to bring
> mitigation resources to bear in a dynamic and optimal fashion within single
> spans of administrative control; and there are standards-based efforts
> underway to provide for a higher degree of automation, increased rapidity
> of response, and interoperability in both inter- and intra-network DDoS
> mitigation scenarios.
>
> ---
> Roland Dobbins 
>

Re: BGP FlowSpec

[Roland Dobbins]

On 2 May 2016, at 20:16, Martin Bacher wrote:

 However, Tier 1s and most probably also some of the Tier 2s may not 
want to offer it to customers because they are loosing money if less 
traffic is sent downstream on IP-Transit links.


I will go a step further than Danny's comments and state that this is 
categorically and demonstrably untrue.


Many of the quite large 'Tier-1' and 'Tier-2' (using the old 
terminology) operators on this list offer commercial DDoS mitigation 
services making use of technologies like D/RTBH, S/RTBH, IDMS, et. al. 
due to customer demand.  They need these capabilities in order to defend 
their own properties and assets, and they are also offering them to 
end-customers who want and need them.


In point of fact, it's becoming difficult to find one which *doesn't* 
offer this type of service.


There were a couple of situations in the first half of the first decade 
of this millennium where operators took this attitude.  But they changed 
their tunes pretty rapidly once they themselves were impacted, and once 
they started losing customers because they couldn't and wouldn't protect 
them.


And as Danny notes, these technologies are all tools in the toolbox.  
NFV and 'SDN' have tremendous potential to make it a lot easier to bring 
mitigation resources to bear in a dynamic and optimal fashion within 
single spans of administrative control; and there are standards-based 
efforts underway to provide for a higher degree of automation, increased 
rapidity of response, and interoperability in both inter- and 
intra-network DDoS mitigation scenarios.


---
Roland Dobbins 

Re: BGP FlowSpec

[Danny McPherson]

On 2016-05-02 09:16 AM, Martin Bacher wrote:


I mainly agree on that. However, I have not found evidence of inter-AS
S-RTBH deployments as of now. This would really require, at least in
my understanding, a lot of hacks in order to implement it properly and
avoid blackholing of the wrong traffic. BGP-FS is clearly doing a
better job in that area. However, Tier 1s and most probably also some
of the Tier 2s may not want to offer it to customers because they are
loosing money if less traffic is sent downstream on IP-Transit links.


While possibly true in an small number of circumstance, I think that's a 
fairly naive view of the issue.  That said, preventing collateral damage 
on the trajectory towards network egress was one of the primary drivers 
for destination-based RTBH (sacrifice the target to save the lot).




Great. Thanks for sharing that. One must just make sure that the tools
are used properly. High volume attacks can easily mitigated in many
cases with BGP-FS while while other attacks like low bandwidth TCP
attacks will have to be mitigated by scrubbing centers.


Even some of those can be mitigated with network and transport layer 
controls, but certainly, there are places where you need application 
layer "scrubbing".



@SDN/NFV: I am not so sure if this will really help or make things
just more complicated. I have just been told that people are working
on netconf/yang solutions for ACL deployments, which may again only
work for intra-AS deployments. But your comment is going, at least in
my understand, beyond ACL deployments, right? Could you please
elaborate a bit further on that.


All these techniques (from ACLs to BGP* to SDN) are all effectively 
about programming the forwarding path, albeit with more and more 
granularity, it's just a matter of where and what the management/control 
plane is.  I agree with your intra-AS comment.


-danny

Re: BGP FlowSpec

[Danny McPherson]

On 2016-05-02 09:48 AM, Martin Bacher wrote:



So filtering as precise as possible and as close as possible to the
attack source is maybe the best option we have at the moment.


That was precisely my point!  If an upstream isn't filtering at their 
ingress (or their egress) the optimal place for me to filter is at my 
ingress.  Of course I'd rather have something akin to inter-domain 
pushback or FlowSpec, etc..  But you can't control how, or assume others 
will act on that.



-danny

Re: BGP FlowSpec

[Martin Bacher]

> Am 02.05.2016 um 15:03 schrieb Alexander Maassen :
> 
> On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote:
>> We use it effectively in a layered model where "Principle of Minimal
>> Intervention" applies, allowing attack mitigation and traffic diversion
>> in the most optimal place (e.g., at network ingress), and only scrubbing
>> or diverting traffic when necessary.
> 
> Sorry to say, but the most optimal place for ddos mitigation is at network
> egress of origin. What comes in mind regarding that is the ability for
> target ASN telling source ASN to stop sending packets from a specific
> (let's say /29) in the case of a DDoS (with appropiate security measures
> in place off course).
> 
> Because, let's face it, why would a target of a ddos need to nullroute
> itself?

Well, I think ingress filtering at the Internet edge (see BCP38 and BCP84) 
would be the best approach. But we as Internet community are clearly failing in 
that area. And origin ASes of amplification and reflection attacks are most 
probably not able to detect DNS ANY queries or NTP monlist queries at a low 
rate without DPI. The networks used for reflection and amplification may be 
able to detect an ongoing attack and they will then hopefully fix their 
implementations and not deploy egress filters.

So the question is how to get rid of source IP address spoofing at all? I don’t 
see any chance by now to push ASes, which are not filtering properly, to 
implement ingress filtering. What could help is to add session handling to UDP 
based protocols as proposed by Christian Rossow and implemented by Google in 
Quic. But that’s again just a workaround and may create new problems because of 
backwards compatibility issues. 

So filtering as precise as possible and as close as possible to the attack 
source is maybe the best option we have at the moment.

> 
> 

Re: BGP FlowSpec

[Shane Short]

+1
I use this to block all kinds of unwanted traffic (with prejudice, of course).


> On 1 May 2016, at 11:56 AM, Roland Dobbins  wrote:
> 
>> On 30 Apr 2016, at 19:56, Pierre Lamy wrote:
>> 
>> to null out the destination rather than the source.
> 
> 
> 
> ---
> Roland Dobbins 

Re: BGP FlowSpec

[Martin Bacher]

> Am 02.05.2016 um 14:30 schrieb Danny McPherson :
> 
> 
> 
> On 2016-04-28 02:31 AM, Martin Bacher wrote:
> 
>>> Literally the only people who were interested in it at the time was one
>>> of the spec's co-authors.  :-)
>> That’s how it usually starts. ;)
> 
> 
> Given that I may be the guilty one here, I thought it might be worth chiming 
> in.
> 
> Inter-AS FlowSpec largely met the same fate as inter-AS source-based RTBH, 
> where upstreams would only want to permit you to block sources destined for 
> your address blocks (i.e.,. not others, so you would have to specify extended 
> drop rule sets -- at least source and destination).  
I mainly agree on that. However, I have not found evidence of inter-AS S-RTBH 
deployments as of now. This would really require, at least in my understanding, 
a lot of hacks in order to implement it properly and avoid blackholing of the 
wrong traffic. BGP-FS is clearly doing a better job in that area. However, Tier 
1s and most probably also some of the Tier 2s may not want to offer it to 
customers because they are loosing money if less traffic is sent downstream on 
IP-Transit links. What I would expect to see more often is iBGP deployments in 
order to protect the own infrastructure by remarking suspicious traffic to 
worst than best effort automatically. That’s again an example why BGP-FS in 
inter-AS setups may not be deployed on a large scale and things may stay worse 
for the Internet edge (and I still hope that I am wrong with that assumption).

> As a result, with inter-AS FlowSpec, to appropriately scope things ingress 
> policy specification is more complicated and hardware support was pretty 
> limited at the time as well.  Additionally, there was also only one vendor 
> implementation at the time but now there are many and the IETF's IDR working 
> group is continuing to enhance the capabilities and options available with 
> FlowSpec.
Yes, I have also noticed that. And the hardware support and inter-AS 
verification options are much better compared to the very beginning. 

> 
> There are a large number of intra-AS and multi-AS single administrative 
> domains that use FlowSpec today (my $dayjob included, for an array of things, 
> not just DDoS mitigation).  And as you point out Martin, it's simply another 
> option available in the toolkit.
I personally think that it will really become standard for single 
administrative domains in the future as it is with L2VPNs and L3VPNs. Most of 
the AS will just deploy it and use it for DDoS mitigation and other 
applications. You just mentioned that you also used for other things. May I ask 
you about your use-cases?

> 
> One of the nicest things about it is that unlike destination-based RTBH, 
> where you effectively completed the attack, if you can identify the 
> primitives, namely at the network and transport layer, you can squelch a 
> large number of attack vectors in an automated manner with minimal action 
> required by the operator.
Could not agree more.

> 
> We use it effectively in a layered model where "Principle of Minimal 
> Intervention" applies, allowing attack mitigation and traffic diversion in 
> the most optimal place (e.g., at network ingress), and only scrubbing or 
> diverting traffic when necessary.  Just like destination and source-based 
> RTBH, FlowSpec is simply another evolution of automating forwarding path 
> configuration, where NFV/SDN are the newest incarnation and can allows 
> badness such as DDoS to be dropped implicitly rather than explicitly, even…
Great. Thanks for sharing that. One must just make sure that the tools are used 
properly. High volume attacks can easily mitigated in many cases with BGP-FS 
while while other attacks like low bandwidth TCP attacks will have to be 
mitigated by scrubbing centers. 

@SDN/NFV: I am not so sure if this will really help or make things just more 
complicated. I have just been told that people are working on netconf/yang 
solutions for ACL deployments, which may again only work for intra-AS 
deployments. But your comment is going, at least in my understand, beyond ACL 
deployments, right? Could you please elaborate a bit further on that.

Many thanks.

Martin

> 
> 
> -danny
> 

Re: BGP FlowSpec

[Alexander Maassen]

On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote:
> We use it effectively in a layered model where "Principle of Minimal
> Intervention" applies, allowing attack mitigation and traffic diversion
> in the most optimal place (e.g., at network ingress), and only scrubbing
> or diverting traffic when necessary.

Sorry to say, but the most optimal place for ddos mitigation is at network
egress of origin. What comes in mind regarding that is the ability for
target ASN telling source ASN to stop sending packets from a specific
(let's say /29) in the case of a DDoS (with appropiate security measures
in place off course).

Because, let's face it, why would a target of a ddos need to nullroute
itself?

Re: BGP FlowSpec

[Danny McPherson]

On 2016-04-28 02:31 AM, Martin Bacher wrote:



Literally the only people who were interested in it at the time was 
one

of the spec's co-authors.  :-)

That’s how it usually starts. ;)



Given that I may be the guilty one here, I thought it might be worth 
chiming in.


Inter-AS FlowSpec largely met the same fate as inter-AS source-based 
RTBH, where upstreams would only want to permit you to block sources 
destined for your address blocks (i.e.,. not others, so you would have 
to specify extended drop rule sets -- at least source and destination).  
As a result, with inter-AS FlowSpec, to appropriately scope things 
ingress policy specification is more complicated and hardware support 
was pretty limited at the time as well.  Additionally, there was also 
only one vendor implementation at the time but now there are many and 
the IETF's IDR working group is continuing to enhance the capabilities 
and options available with FlowSpec.


There are a large number of intra-AS and multi-AS single administrative 
domains that use FlowSpec today (my $dayjob included, for an array of 
things, not just DDoS mitigation).  And as you point out Martin, it's 
simply another option available in the toolkit.


One of the nicest things about it is that unlike destination-based RTBH, 
where you effectively completed the attack, if you can identify the 
primitives, namely at the network and transport layer, you can squelch a 
large number of attack vectors in an automated manner with minimal 
action required by the operator.


We use it effectively in a layered model where "Principle of Minimal 
Intervention" applies, allowing attack mitigation and traffic diversion 
in the most optimal place (e.g., at network ingress), and only scrubbing 
or diverting traffic when necessary.  Just like destination and 
source-based RTBH, FlowSpec is simply another evolution of automating 
forwarding path configuration, where NFV/SDN are the newest incarnation 
and can allows badness such as DDoS to be dropped implicitly rather than 
explicitly, even...



-danny

Re: BGP FlowSpec

[Roland Dobbins]

On 30 Apr 2016, at 19:56, Pierre Lamy wrote:

> to null out the destination rather than the source.



---
Roland Dobbins 

Re: BGP FlowSpec

[Pierre Lamy]

I was looking into using this mechanism for blocking DDoS on Juniper
devices, but at the time, they only supported 8k flowspec entries/routes
and this was not sufficient to deal with the problem. My fallback was to
poison the routing table with null routes, but the problem with this was
that it didn't address inbound traffic, only the replies.

We ended up ditching all of this in favor of a third party external
scubbing vendor. They tend to prefer big honking boxes running
signatures whereever possible to drop identified malicious traffic.

When you get right down to it, the vendors have a lot of experience
day-to-day performing mitigations, and flowspec (or other BGP
mitigations) are more useful to carriers and ISPs to null out the
destination rather than the source.

Pierre

On 29/04/2016 9:08 AM, dennis wrote:
> 
> 
> Hi
> Amplification attacks and syn floods are just touching the surface of ddos 
> attack vectors.  You should look into some industry reports:
> Here are a couple examples to get you started.
> https://www.radware.com/ert-report-2015/
> http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/
> 
> Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone
> 
>  Original message 
> From: Martin Bacher  
> Date: 4/29/2016  2:02 AM  (GMT-08:00) 
> To: Tyler Haske  
> Cc: NANOG list  
> Subject: Re: BGP FlowSpec 
> 
> Hello Tyler,
> 
> thanks for your reply.
> 
>> Am 28.04.2016 um 17:37 schrieb Tyler Haske :
>>
>> Martin,
>>
>>
>>> Last but not least: I am also looking for anonymized statistical data about 
>>> DDoS attacks which I could use in the thesis. I am mainly interested in 
>>> data about the
>>> type of attacks, attack time, sources, source and destination ports, and so 
>>> on. I know this something which is generally not shared, so I would really 
>>> appreciate it if
>>> someone would be able to share such data.
>>
>> Many companies are extremely reluctant to share their attack data. But 
>> that's OK, because there are other ways to get it.
>>
>> Have you investigated backscatter analysis? It's used to see ongoing and 
>> current Internet scope DDoS attacks.
> I just had a look on that and thought that its only be able to detect some of 
> the attacks. You might not detect large state of the art reflection and 
> amplification attacks with that method. But i think it is useful for some 
> sort of attacks like SYN flood. Do you agree?
> 
>>
>> Inferring Internet Denial of Service Activity
>> https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf
>>
>> Analyzing Large DDoS Attacks Using Multiple Data Sources
>> https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf
>>
>> ISP Security - Real World Techniques
>> https://www.nanog.org/meetings/nanog23/presentations/greene.ppt
>>
>> A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a 
>> Service Provider Environment
>> https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212
>>
>> Maybe you have access to some public IPs, then you can do this data 
>> collection yourself.
> Sure, I will definitely think about hat.
> 
> Thanks again for your reply and for providing the links.
> 
> Greetings,
> Martin
> 
>>
>> Regards,
>>
>> Tyler
>>
> 
> 

Re: BGP FlowSpec

[dennis]

Hi
Amplification attacks and syn floods are just touching the surface of ddos 
attack vectors.  You should look into some industry reports:
Here are a couple examples to get you started.
https://www.radware.com/ert-report-2015/
http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/

Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone

 Original message 
From: Martin Bacher  
Date: 4/29/2016  2:02 AM  (GMT-08:00) 
To: Tyler Haske  
Cc: NANOG list  
Subject: Re: BGP FlowSpec 

Hello Tyler,

thanks for your reply.

> Am 28.04.2016 um 17:37 schrieb Tyler Haske :
> 
> Martin,
> 
> 
> > Last but not least: I am also looking for anonymized statistical data about 
> > DDoS attacks which I could use in the thesis. I am mainly interested in 
> > data about the
> > type of attacks, attack time, sources, source and destination ports, and so 
> > on. I know this something which is generally not shared, so I would really 
> > appreciate it if
> > someone would be able to share such data.
> 
> Many companies are extremely reluctant to share their attack data. But that's 
> OK, because there are other ways to get it.
> 
> Have you investigated backscatter analysis? It's used to see ongoing and 
> current Internet scope DDoS attacks.
I just had a look on that and thought that its only be able to detect some of 
the attacks. You might not detect large state of the art reflection and 
amplification attacks with that method. But i think it is useful for some sort 
of attacks like SYN flood. Do you agree?

> 
> Inferring Internet Denial of Service Activity
> https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf
> 
> Analyzing Large DDoS Attacks Using Multiple Data Sources
> https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf
> 
> ISP Security - Real World Techniques
> https://www.nanog.org/meetings/nanog23/presentations/greene.ppt
> 
> A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a 
> Service Provider Environment
> https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212
> 
> Maybe you have access to some public IPs, then you can do this data 
> collection yourself.
Sure, I will definitely think about hat.

Thanks again for your reply and for providing the links.

Greetings,
Martin

> 
> Regards,
> 
> Tyler
> 

Re: BGP FlowSpec

[Martin Bacher]

Hello Tyler,

thanks for your reply.

> Am 28.04.2016 um 17:37 schrieb Tyler Haske :
> 
> Martin,
> 
> 
> > Last but not least: I am also looking for anonymized statistical data about 
> > DDoS attacks which I could use in the thesis. I am mainly interested in 
> > data about the
> > type of attacks, attack time, sources, source and destination ports, and so 
> > on. I know this something which is generally not shared, so I would really 
> > appreciate it if
> > someone would be able to share such data.
> 
> Many companies are extremely reluctant to share their attack data. But that's 
> OK, because there are other ways to get it.
> 
> Have you investigated backscatter analysis? It's used to see ongoing and 
> current Internet scope DDoS attacks.
I just had a look on that and thought that its only be able to detect some of 
the attacks. You might not detect large state of the art reflection and 
amplification attacks with that method. But i think it is useful for some sort 
of attacks like SYN flood. Do you agree?

> 
> Inferring Internet Denial of Service Activity
> https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf
> 
> Analyzing Large DDoS Attacks Using Multiple Data Sources
> https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf
> 
> ISP Security - Real World Techniques
> https://www.nanog.org/meetings/nanog23/presentations/greene.ppt
> 
> A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a 
> Service Provider Environment
> https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212
> 
> Maybe you have access to some public IPs, then you can do this data 
> collection yourself.
Sure, I will definitely think about hat.

Thanks again for your reply and for providing the links.

Greetings,
Martin

> 
> Regards,
> 
> Tyler
> 

Re: BGP FlowSpec

[Tyler Haske]

Martin,


> Last but not least: I am also looking for anonymized statistical data
about DDoS attacks which I could use in the thesis. I am mainly interested
in data about the
> type of attacks, attack time, sources, source and destination ports, and
so on. I know this something which is generally not shared, so I would
really appreciate it if
> someone would be able to share such data.

Many companies are extremely reluctant to share their attack data. But
that's OK, because there are other ways to get it.

Have you investigated backscatter analysis? It's used to see ongoing and
current Internet scope DDoS attacks.

Inferring Internet Denial of Service Activity
https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf

Analyzing Large DDoS Attacks Using Multiple Data Sources
https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf

ISP Security - Real World Techniques
https://www.nanog.org/meetings/nanog23/presentations/greene.ppt

A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a
Service Provider Environment
https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212

Maybe you have access to some public IPs, then you can do this data
collection yourself.

Regards,

Tyler

Re: BGP FlowSpec

[Martin Bacher]

> Am 27.04.2016 um 18:09 schrieb Hank Nussbacher :
> 
> On 27/04/2016 18:58, John Kristoff wrote:
>> On Thu, 21 Apr 2016 09:46:13 +0200
>> Martin Bacher  wrote:
>> 
>>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>>> of attacks are you using it? Are you only dropping or rate-limiting
>>> certain traffic or are you also using the redirect/remark
>>> capabilities? What are the limitations from your perspective? Are you
>>> facing any operational issues? How are you injecting the FlowSpec
>>> routes?
>> Unless you received a number of private responses, perhaps the lack of
>> public responses is telling.
> Geant runs a Firewall of Demand based on BGP Flowspec (Juniper
> routers).  You can read more about it here:
> http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf
> https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf
Thank you Hank. That’s a pretty nice intra AS implementation with a nice 
interface for customers. 

Cheers,
Martin

> 
> Regards,
> Hank
> 
>> 
>> I've heard of a few networks doing this and there is some public record
>> of it being used, including one instance where a bad rule was behind a
>> serious outage:
>> 
>>  
>> <https://support.cloudflare.com/hc/en-us/articles/200172446-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013>
>> 
>>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>>> your experience? Are there any concerns regarding Inter-AS
>>> deployments? Has anyone done interop tests?
>> You might mine public, archived BGP data and see if there are any
>> traffic filtering rules present (they are encoded in extended
>> communities, which are optional, transitive).
>> 
>> We once tried to coordinate an Inter-AS flow-spec project, but it
>> failed miserably due to lack of interest.  For posterity, here is the
>> project page:
>> 
>>  <https://www.cymru.com/jtk/misc/community-fs.html>
>> 
>> Literally the only people who were interested in it at the time was one
>> of the spec's co-authors.  :-)
>> 
>> Since then, we have tried a more modest approach using the well known
>> BGP RTBH technique:
>> 
>>  <https://www.cymru.com/jtk/misc/utrs.html>
>> 
>> This has been much more successful and since we've started we've
>> probably had about a dozen networks express interest in flow-spec
>> rules.  Verification of rules is potentially tricky, but
>> widespread interest still lags in my estimation.
>> 
>>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>>> and which applications are you using for the analysis (Peakflow,
>>> Open-Source tools, ..?)
>> Not speaking for anyone in particular, but don't forget about user
>> complaints.  In some cases a network may not notice (or care) if an
>> attack is below a certain threshold for their network, but above a
>> stress point downstream.
>> 
>> John
>> 
> 

Re: BGP FlowSpec

[Martin Bacher]

> Am 27.04.2016 um 17:58 schrieb John Kristoff :
> 
> On Thu, 21 Apr 2016 09:46:13 +0200
> Martin Bacher  wrote:
> 
>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>> of attacks are you using it? Are you only dropping or rate-limiting
>> certain traffic or are you also using the redirect/remark
>> capabilities? What are the limitations from your perspective? Are you
>> facing any operational issues? How are you injecting the FlowSpec
>> routes?
> 
> Unless you received a number of private responses, perhaps the lack of
> public responses is telling.
> 
> I've heard of a few networks doing this and there is some public record
> of it being used, including one instance where a bad rule was behind a
> serious outage:
> 
>  
> <https://support.cloudflare.com/hc/en-us/articles/200172446-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013>

Thanks for that information.  I didn’t know about that outage and this is 
definitely something which is very important and worth mentioning in the paper. 
But i would rather say that this is a general risk. A fat fingers issue can 
always disconnect you from the internet as well as a software bug in a 
homogenous environment.

> 
>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>> your experience? Are there any concerns regarding Inter-AS
>> deployments? Has anyone done interop tests?
> 
> You might mine public, archived BGP data and see if there are any
> traffic filtering rules present (they are encoded in extended
> communities, which are optional, transitive).

I don’t think that I will find anything there because it is a dedicated SAFI. 
Only traffic filtering actions are encoded as extended communities.
> 
> We once tried to coordinate an Inter-AS flow-spec project, but it
> failed miserably due to lack of interest.  For posterity, here is the
> project page:
> 
>  <https://www.cymru.com/jtk/misc/community-fs.html>

I already came across your project but didn’t recognize that there is/was also 
some FlowSpec initiative.

> 
> Literally the only people who were interested in it at the time was one
> of the spec's co-authors.  :-)
That’s how it usually starts. ;)

> 
> Since then, we have tried a more modest approach using the well known
> BGP RTBH technique:
> 
>  <https://www.cymru.com/jtk/misc/utrs.html>
> 
> This has been much more successful and since we've started we've
> probably had about a dozen networks express interest in flow-spec
> rules.  Verification of rules is potentially tricky, but
> widespread interest still lags in my estimation.
Yes, RTBH is quite common and really helpful in the inter AS world. But eBGP 
FlowSpec is just offered by very few ISPs. I think that intra AS deployments 
are more common, but one wouldn’t be able to detect that unless somebody tells 
you that they are using it.

> 
>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>> and which applications are you using for the analysis (Peakflow,
>> Open-Source tools, ..?)
> 
> Not speaking for anyone in particular, but don't forget about user
> complaints.  In some cases a network may not notice (or care) if an
> attack is below a certain threshold for their network, but above a
> stress point downstream.
That’s true. They are selling IP-Transit and more traffic means more money. 
Upstream providers may only care if other customers are also affected or unless 
you pay them for protection.

Thanks for your comments!

Cheers,
Martin

> 
> John

Re: BGP FlowSpec

[Hank Nussbacher]

On 27/04/2016 18:58, John Kristoff wrote:
> On Thu, 21 Apr 2016 09:46:13 +0200
> Martin Bacher  wrote:
>
>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>> of attacks are you using it? Are you only dropping or rate-limiting
>> certain traffic or are you also using the redirect/remark
>> capabilities? What are the limitations from your perspective? Are you
>> facing any operational issues? How are you injecting the FlowSpec
>> routes?
> Unless you received a number of private responses, perhaps the lack of
> public responses is telling.
Geant runs a Firewall of Demand based on BGP Flowspec (Juniper
routers).  You can read more about it here:
http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf
https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf

Regards,
Hank

>
> I've heard of a few networks doing this and there is some public record
> of it being used, including one instance where a bad rule was behind a
> serious outage:
>
>   
> <https://support.cloudflare.com/hc/en-us/articles/200172446-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013>
>
>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>> your experience? Are there any concerns regarding Inter-AS
>> deployments? Has anyone done interop tests?
> You might mine public, archived BGP data and see if there are any
> traffic filtering rules present (they are encoded in extended
> communities, which are optional, transitive).
>
> We once tried to coordinate an Inter-AS flow-spec project, but it
> failed miserably due to lack of interest.  For posterity, here is the
> project page:
>
>   <https://www.cymru.com/jtk/misc/community-fs.html>
>
> Literally the only people who were interested in it at the time was one
> of the spec's co-authors.  :-)
>
> Since then, we have tried a more modest approach using the well known
> BGP RTBH technique:
>
>   <https://www.cymru.com/jtk/misc/utrs.html>
>
> This has been much more successful and since we've started we've
> probably had about a dozen networks express interest in flow-spec
> rules.  Verification of rules is potentially tricky, but
> widespread interest still lags in my estimation.
>
>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>> and which applications are you using for the analysis (Peakflow,
>> Open-Source tools, ..?)
> Not speaking for anyone in particular, but don't forget about user
> complaints.  In some cases a network may not notice (or care) if an
> attack is below a certain threshold for their network, but above a
> stress point downstream.
>
> John
>

Re: BGP FlowSpec

[John Kristoff]

On Thu, 21 Apr 2016 09:46:13 +0200
Martin Bacher  wrote:

> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
> of attacks are you using it? Are you only dropping or rate-limiting
> certain traffic or are you also using the redirect/remark
> capabilities? What are the limitations from your perspective? Are you
> facing any operational issues? How are you injecting the FlowSpec
> routes?

Unless you received a number of private responses, perhaps the lack of
public responses is telling.

I've heard of a few networks doing this and there is some public record
of it being used, including one instance where a bad rule was behind a
serious outage:

  
<https://support.cloudflare.com/hc/en-us/articles/200172446-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013>

> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
> your experience? Are there any concerns regarding Inter-AS
> deployments? Has anyone done interop tests?

You might mine public, archived BGP data and see if there are any
traffic filtering rules present (they are encoded in extended
communities, which are optional, transitive).

We once tried to coordinate an Inter-AS flow-spec project, but it
failed miserably due to lack of interest.  For posterity, here is the
project page:

  <https://www.cymru.com/jtk/misc/community-fs.html>

Literally the only people who were interested in it at the time was one
of the spec's co-authors.  :-)

Since then, we have tried a more modest approach using the well known
BGP RTBH technique:

  <https://www.cymru.com/jtk/misc/utrs.html>

This has been much more successful and since we've started we've
probably had about a dozen networks express interest in flow-spec
rules.  Verification of rules is potentially tricky, but
widespread interest still lags in my estimation.

> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
> and which applications are you using for the analysis (Peakflow,
> Open-Source tools, ..?)

Not speaking for anyone in particular, but don't forget about user
complaints.  In some cases a network may not notice (or care) if an
attack is below a certain threshold for their network, but above a
stress point downstream.

John

BGP FlowSpec

[Martin Bacher]

Dear Nanog Members,

My name is Martin Bacher. I am a Student at UAS Technikum-Wien and I am 
currently writing my master’s thesis with topic "Addressing DDoS Attacks with 
BGP FlowSpec“.

It would be very helpful for me if some of you could share information about 
the following topics:
- Intra-AS BGP FlowSpec deployment: Who is running it? For which kind of 
attacks are you using it? Are you only dropping or rate-limiting certain 
traffic or are you also using the redirect/remark capabilities? What are the 
limitations from your perspective? Are you facing any operational issues? How 
are you injecting the FlowSpec routes?
- Inter-AS: Who is running Inter-AS FlowSpec deployments? What is your 
experience? Are there any concerns regarding Inter-AS deployments? Has anyone 
done interop tests?

FlowSpec is usually only one part of the whole anti DDoS toolset. So I would 
also be interested in your answers to the following questions:
- How are you detecting DDoS attacks (Netflow, in-line probes, ..?) and which 
applications are you using for the analysis (Peakflow, Open-Source tools, ..?)
- Which countermeasures are you deploying in case of DDoS attacks? ACLs, 
FlowSpec, Blackhole routes, RTBH, scrubbing center, Cloud based DDoS services 
or anything else?
- What is your operational experience? How fast are you in deploying 
countermeasures? Do you have any automation or is this always triggered by 
people?

Last but not least: I am also looking for anonymized statistical data about 
DDoS attacks which I could use in the thesis. I am mainly interested in data 
about the type of attacks, attack time, sources, source and destination ports, 
and so on. I know this something which is generally not shared, so I would 
really appreciate it if someone would be able to share such data.

Please send me your answers either via pn or directly to the list. Please also 
let me know if you think that there is something missing. Any comment or answer 
is highly appreciated.

Looking forward to your replies.

Many thanks.

Greetings,
Martin

BGP Flowspec Survey

[Justin Ryburn]

Hey Everyone,

I am looking to get feedback from the community on BGP Flowspec for an upcoming 
presentation...

https://www.surveymonkey.com/s/RZYQ23S <https://www.surveymonkey.com/s/RZYQ23S>

Feel free to forward this to any contacts you may have that are not on the 
NANOG list. Obviously, the more response I get, the more accurate the data will 
be.

Let me know if you have any questions.

Thanks,
-Justin


Justin Ryburn
Senior Systems Engineer
Juniper Networks

Re: upstream support for flowspec

[joel jaeggli]

On 9/18/14 11:06 AM, John Kristoff wrote:
> On Thu, 18 Sep 2014 13:53:52 -0400
> Daniel Corbe  wrote:
> 
>> Is there anything in the air about widening the adoption base?  Cisco?
>> Brocade?
> 
> I've seen some suggesting that increased support, but even at Juniper,
> actions seem to speak larger than words.  There seems to be very little
> interest for awhile now.  However, I do know of some providers who use
> it, largely internal only.

afaik from some previous experience it was hard to know a-priori which
flow-spec route insertion was going to cause aberrant performance on the
juniper platforms we were using.

That's kinda ok if you use them since at least you can be aware of and
revert that if it proves to be a problem. but it's kind of handing your
customer a loaded gun.

> We also have tried a community flow-spec service, and more recently
> have been prototyping a community RTBH server with flow-spec capability
> (ping me off list if you want to hear more or see me at NANOG 62).
> 
> A few people have recently told me they would like our community RTBH
> service via flow-spec instead of just BGP next hop, but really only one
> seemed seriously intent on configuring it day one.
> 
> John
> 




signature.asc
Description: OpenPGP digital signature

Re: upstream support for flowspec

[joel jaeggli]

On 9/18/14 1:19 PM, Job Snijders wrote:
> On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote:
> 
>>> a) you're paying less, as you're not receiving the traffic
>>
>> This ventures into the realm of an operator doing something responsible
>> to protect me vs routing me unwanted traffic and going "lol, bill."
>>
>> If you want to start playing that game, I'm happy to pay more per mbit
>> of traffic if you're happy to guarantee me that you won't route me
>> traffic that I'm expressly uninterested in.
> 
> Would you be willing to pay for the traffic _not_ delivered to you
> because of customer-pushed ACLs? If so, that would take the argument
> away "because we filter we can't bill". Would you be willing to pay a
> premium to be able to do so? Is it worth a premium to insert ACLs in
> real time in the upstream's network or is a 2 hour delay acceptable?
> what about 5 minute delay? 

It's not really a question we have to ask. Managed firewall services
have way higher margins then pure IP transit. By extension dropping
packets can be substantially more profitable especially on a per packet
or byte basis then delivering them. Not everyone wants that service however.

> Aside from practical issues with flowspec as Ytti mentioned already, I
> don't think the market has yet figured out how stuff like this should
> work and become cost-effective.

Ah cost effective is a consideration, yeah that is a bit of a bummer.

> Kind regards,
> 
> Job
> 




signature.asc
Description: OpenPGP digital signature

Re: upstream support for flowspec

[Job Snijders]

On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote:

> > a) you're paying less, as you're not receiving the traffic
> 
> This ventures into the realm of an operator doing something responsible
> to protect me vs routing me unwanted traffic and going "lol, bill."
> 
> If you want to start playing that game, I'm happy to pay more per mbit
> of traffic if you're happy to guarantee me that you won't route me
> traffic that I'm expressly uninterested in.

Would you be willing to pay for the traffic _not_ delivered to you
because of customer-pushed ACLs? If so, that would take the argument
away "because we filter we can't bill". Would you be willing to pay a
premium to be able to do so? Is it worth a premium to insert ACLs in
real time in the upstream's network or is a 2 hour delay acceptable?
what about 5 minute delay? 

Aside from practical issues with flowspec as Ytti mentioned already, I
don't think the market has yet figured out how stuff like this should
work and become cost-effective.

Kind regards,

Job

Re: upstream support for flowspec

[Job Snijders]

On Thu, Sep 18, 2014 at 03:15:41PM -0400, Daniel Corbe wrote:
> Also, if I'm buying full line rate commit from you then you're not
> actually losing any money on the deal whether or not you route me the
> traffic.

Ha, I wish all customers would buy in full line rate commits! :-)

- Job

Re: upstream support for flowspec

[Daniel Corbe]

Also, if I'm buying full line rate commit from you then you're not
actually losing any money on the deal whether or not you route me the
traffic.

-Daniel

Daniel Corbe  writes:

> Saku Ytti  writes:
>
>> On (2014-09-18 13:53 -0400), Daniel Corbe wrote:
>>
>> Hi Daniel,
>>
>>> This seems like it would be a godsend for small operators like
>>> myself who don't have
>>> access to unlimited bandwidth and are put off by off-site scrubbing
>>> services.  
>>> 
>>> As far as I can tell though the only platforms that offer support are
>>> the 7750-SR and platforms made by Juniper.
>>
>> Cisco IOS-XR supports flowspec today as well.
>>
>> How much more would you pay per Mbps/month to have operator offer flowspec?
>> IP transit is quite low margin product, supporting flowspec may have some
>> adverse effects to business case:
>>
>> a) you're paying less, as you're not receiving the traffic
>
> This ventures into the realm of an operator doing something responsible
> to protect me vs routing me unwanted traffic and going "lol, bill."
>
> If you want to start playing that game, I'm happy to pay more per mbit
> of traffic if you're happy to guarantee me that you won't route me
> traffic that I'm expressly uninterested in.
>
>> b) operator may get more traffic, as attack does not yield desired
>> outcome
>
> Not necessarily true.  If I can identify and push malicious traffic
> towards your edge, then you can do the same towards your peers. 
>
> If I can ask you to filter by source, can you turn around and do so by
> source *AND* destination?  You know what I'm announcing, so it seems
> like this ought to be possible.  Short of that, it would require us to
> be in a trust relationship and I can see how that would be problematic.
>
> If we circle back around to paying a premium for the service, then I'm
> going to expect you to absorb the attack on my behalf.
>
>
>>
>> And when we look at the feature technically
>>
>> a) junos does not allow setting flowspec on in FW filters and then apply FW
>> filter where you wish to do it, it's automatically turned on for all traffic
>> transiting box. This may be undesirable.
>>
>> b) by default junos accepts all flowspec actions, such as diverting traffic 
>> to
>> new IP or new VRF. This may cause undesirable security issues.
>>
>> c) added feature == added complexity == reduced availability
>
> -Daniel

Re: upstream support for flowspec

[Daniel Corbe]

Saku Ytti  writes:

> On (2014-09-18 13:53 -0400), Daniel Corbe wrote:
>
> Hi Daniel,
>
>> This seems like it would be a godsend for small operators like
>> myself who don't have
>> access to unlimited bandwidth and are put off by off-site scrubbing
>> services.  
>> 
>> As far as I can tell though the only platforms that offer support are
>> the 7750-SR and platforms made by Juniper.
>
> Cisco IOS-XR supports flowspec today as well.
>
> How much more would you pay per Mbps/month to have operator offer flowspec?
> IP transit is quite low margin product, supporting flowspec may have some
> adverse effects to business case:
>
> a) you're paying less, as you're not receiving the traffic

This ventures into the realm of an operator doing something responsible
to protect me vs routing me unwanted traffic and going "lol, bill."

If you want to start playing that game, I'm happy to pay more per mbit
of traffic if you're happy to guarantee me that you won't route me
traffic that I'm expressly uninterested in.

> b) operator may get more traffic, as attack does not yield desired
> outcome

Not necessarily true.  If I can identify and push malicious traffic
towards your edge, then you can do the same towards your peers. 

If I can ask you to filter by source, can you turn around and do so by
source *AND* destination?  You know what I'm announcing, so it seems
like this ought to be possible.  Short of that, it would require us to
be in a trust relationship and I can see how that would be problematic.

If we circle back around to paying a premium for the service, then I'm
going to expect you to absorb the attack on my behalf.


>
> And when we look at the feature technically
>
> a) junos does not allow setting flowspec on in FW filters and then apply FW
> filter where you wish to do it, it's automatically turned on for all traffic
> transiting box. This may be undesirable.
>
> b) by default junos accepts all flowspec actions, such as diverting traffic to
> new IP or new VRF. This may cause undesirable security issues.
>
> c) added feature == added complexity == reduced availability

-Daniel

Re: upstream support for flowspec

[Saku Ytti]

On (2014-09-18 13:53 -0400), Daniel Corbe wrote:

Hi Daniel,

> This seems like it would be a godsend for small operators like myself who 
> don't have
> access to unlimited bandwidth and are put off by off-site scrubbing
> services.  
> 
> As far as I can tell though the only platforms that offer support are
> the 7750-SR and platforms made by Juniper.

Cisco IOS-XR supports flowspec today as well.

How much more would you pay per Mbps/month to have operator offer flowspec?
IP transit is quite low margin product, supporting flowspec may have some
adverse effects to business case:

a) you're paying less, as you're not receiving the traffic
b) operator may get more traffic, as attack does not yield desired outcome

And when we look at the feature technically

a) junos does not allow setting flowspec on in FW filters and then apply FW
filter where you wish to do it, it's automatically turned on for all traffic
transiting box. This may be undesirable.

b) by default junos accepts all flowspec actions, such as diverting traffic to
new IP or new VRF. This may cause undesirable security issues.

c) added feature == added complexity == reduced availability

-- 
  ++ytti

Re: upstream support for flowspec

[Youssef Bengelloun-Zahr]

Envoyé de mon iPhone

> Le 18 sept. 2014 à 19:53, Daniel Corbe  a écrit :
> 
> 
> I was perusing RFC5575 after reading a presentation that ALU did
> (presumably during some previous NANOG conference).  Reference:
> https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf
> 
> This seems like it would be a godsend for small operators like myself who 
> don't have
> access to unlimited bandwidth and are put off by off-site scrubbing
> services.  
> 
> As far as I can tell though the only platforms that offer support are
> the 7750-SR and platforms made by Juniper.
> 
> Is there anything in the air about widening the adoption base?  Cisco?
> Brocade?

Hi,

I've submitted a request through my Brocade SE to support this, but it seems 
they are not interested about it.

They claim their strategy is to achieve the same using SDN capabilities via 
OPENFLOW support.

In the mean time, we are sitting ducks with our traditional technics.

I read in an old NANOG thread (IIRC) that cisco was about to support this 
really soon on IOS-XR, but I am not 100% sur.

Best regards.

> 
> And once that happens, what are the chances of services providers
> adopting this for their customers to make use of on as wide of a scale
> as (for example) blackhole community strings.
> 
> I'd certainly *love* to have a way to mitigate an attack that doesn't
> involve me sacrificing one service on my network to save the rest.
> 
> Best,
> Daniel

Re: upstream support for flowspec

[Christopher Morrow]

On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe  wrote:
> And once that happens, what are the chances of services providers
> adopting this for their customers to make use of on as wide of a scale
> as (for example) blackhole community strings.
>
> I'd certainly *love* to have a way to mitigate an attack that doesn't
> involve me sacrificing one service on my network to save the rest.

there are providers (verizon business, att, sprint, ntt at least) that
provide mitigation via bgp update... which is equivalent to the
blackhole community stuff, why not investigate those options? (or if
you had, what was lacking?)

Re: upstream support for flowspec

[John Kristoff]

On Thu, 18 Sep 2014 13:53:52 -0400
Daniel Corbe  wrote:

> Is there anything in the air about widening the adoption base?  Cisco?
> Brocade?

I've seen some suggesting that increased support, but even at Juniper,
actions seem to speak larger than words.  There seems to be very little
interest for awhile now.  However, I do know of some providers who use
it, largely internal only.

We also have tried a community flow-spec service, and more recently
have been prototyping a community RTBH server with flow-spec capability
(ping me off list if you want to hear more or see me at NANOG 62).

A few people have recently told me they would like our community RTBH
service via flow-spec instead of just BGP next hop, but really only one
seemed seriously intent on configuring it day one.

John

upstream support for flowspec

[Daniel Corbe]

I was perusing RFC5575 after reading a presentation that ALU did
(presumably during some previous NANOG conference).  Reference:
https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf

This seems like it would be a godsend for small operators like myself who don't 
have
access to unlimited bandwidth and are put off by off-site scrubbing
services.  

As far as I can tell though the only platforms that offer support are
the 7750-SR and platforms made by Juniper.

Is there anything in the air about widening the adoption base?  Cisco?
Brocade?  

And once that happens, what are the chances of services providers
adopting this for their customers to make use of on as wide of a scale
as (for example) blackhole community strings.

I'd certainly *love* to have a way to mitigate an attack that doesn't
involve me sacrificing one service on my network to save the rest.

Best,
Daniel

Re: open source with flowspec ?

[Tom Hill]

On 2014-03-13 23:13, joel jaeggli wrote:

exabgp from ripe labs can inject flowspec routes.


You mean from Exa Networks[1], not RIPE: 
https://github.com/Exa-Networks/exabgp


Tom

[1] http://www.exa.net.uk/

Re: open source with flowspec ?

[joel jaeggli]

exabgp from ripe labs can inject flowspec routes.

typically some helper app would generate the policy for exabgp and then
exabgp would do the heavy lifting.

joel

On 3/13/14, 3:42 PM, Piotr wrote:
> Hi,
> 
> There is some open source sflow collector wich can talk via flowspec
> with juniper routers ? something like snort + nfdump ? I looking
> something besides Arbor because itis too expensive for me.
> 
> thanks for help
> Peter
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: open source with flowspec ?

[ML]

On 3/13/2014 6:42 PM, Piotr wrote:

Hi,

There is some open source sflow collector wich can talk via flowspec 
with juniper routers ? something like snort + nfdump ? I looking 
something besides Arbor because itis too expensive for me.


thanks for help
Peter




I believe the goal of ExaDDOS is what you're looking for.

https://github.com/Exa-Networks/exaddos

open source with flowspec ?

[Piotr]

Hi,

There is some open source sflow collector wich can talk via flowspec 
with juniper routers ? something like snort + nfdump ? I looking 
something besides Arbor because itis too expensive for me.


thanks for help
Peter

Re: Announcing the Community FlowSpec trial

[Christopher Morrow]

On Wed, Jan 5, 2011 at 7:51 PM, Richard A Steenbergen  wrote:
> On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote:
>> Friends and colleagues,
>>
>> At NANOG 48 I talked about a community flow-spec service we were
>> looking at trying to make work.  This is the idea of using IETF RFC
>> 5575 to pass around flow-based rules, in this case, primarily for
>> dropping unwanted packets.



> As a word of warning to anyone who wants to deploy this on their Juniper
> routers (what other router vendors support it? :P), there are some
> pretty serious performance considerations of which you should be aware.
>
> For example, we discovered that on MX routers (with classic I-chip DPCs,
> the performance should be somewhat better for Trio cards but we haven't
> fully tested the exact numbers yet), installing as few as a dozen
> flowspec routes can create firewall filters that use enough SRAM

'as few as a dozen' - of things like:
(forgive the hackery into cisco-ese)
deny ip 127.0.0.0 0.255.255.255 any
permit ip any any

or with port/protocol/flags/sizes/etc ?
(can you provide some examples of your dozen-or-so - give folk a
starting point in their testing)

-chris

Re: Announcing the Community FlowSpec trial

[Richard A Steenbergen]

On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote:
> Friends and colleagues,
> 
> At NANOG 48 I talked about a community flow-spec service we were
> looking at trying to make work.  This is the idea of using IETF RFC
> 5575 to pass around flow-based rules, in this case, primarily for
> dropping unwanted packets.
> 
> This technology is not as widely deployed as traditional RTBH
> techniques for a number of reasons.  However, we thought perhaps it
> was widely used enough, or could be, to justify what might be a
> helpful and free 3rd party feed of flow-spec routes to keep our
> networks a little bit cleaner.
> 
> A trial of this feed based on the traditional bogon routes can be had 
> by contacting me directly.  We realize the traditional IPv4 reserved, 
> special and unallocated IPv4 bogon address is dwindling.  Maybe there 
> is room for some other type of feed, but to justify that, we're 
> looking to see if even enough people would set up this presumably 
> simpler feed to help us and the community get some more experience 
> with multi-hop flow-spec.

As a word of warning to anyone who wants to deploy this on their Juniper 
routers (what other router vendors support it? :P), there are some 
pretty serious performance considerations of which you should be aware.

For example, we discovered that on MX routers (with classic I-chip DPCs, 
the performance should be somewhat better for Trio cards but we haven't 
fully tested the exact numbers yet), installing as few as a dozen 
flowspec routes can create firewall filters that use enough SRAM 
accesses that you will no longer be able to achieve line rate 
packets/sec. With a few more rules, you may find that your 10GE's will 
only be able to handle 3-5Mpps instead of the normal 14.8Mpps. When this 
happens, excess traffic above what the firewall filters can handle will 
be silently discarded, with no indicaton in SNMP or "show interface" 
that you're dropping packets (though you may be able to see it in "show 
pfe statistics traffic" as Info cell drops).

I can't tell you what the performance numbers are for other platforms, 
but anyone thinking about turning on flowspec from a third party source 
(especially one who may be sending them a large number of rules) should 
give serious consideration to the potential impact on their network 
first.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Announcing the Community FlowSpec trial

[John Kristoff]

Friends and colleagues,

At NANOG 48 I talked about a community flow-spec service we were
looking at trying to make work.  This is the idea of using IETF RFC
5575 to pass around flow-based rules, in this case, primarily for
dropping unwanted packets.

This technology is not as widely deployed as traditional RTBH
techniques for a number of reasons.  However, we thought perhaps it
was widely used enough, or could be, to justify what might be a
helpful and free 3rd party feed of flow-spec routes to keep our
networks a little bit cleaner.

A trial of this feed based on the traditional bogon routes can be had
by contacting me directly.  We realize the traditional IPv4 reserved,
special and unallocated IPv4 bogon address is dwindling.  Maybe there
is room for some other type of feed, but to justify that, we're looking
to see if even enough people would set up this presumably simpler feed
to help us and the community get some more experience with multi-hop
flow-spec.

Details in getting it up and running in your own test networks are here:

  

John

BGP FlowSpec (RFC 5575) route injector

[Thomas Mangin]

Hi,

I juste added some preliminary support for FlowSpec (RFC5575) to my BGP route 
injector http://bgp.exa.org.uk/
As I am not aware of any other project allowing to inject flow route into a 
network, I am taking the liberty to plug it here.

You can access the SVN repository at: http:/svn.exa.org.uk/bgp/trunk/ the code 
is under a 3-clauses BSD licence.
More information about the installation are available on the wiki.

I performed basic testing by rate-limiting one of my coworkers mail and web 
flows - seems to work - for the rest, it may not do what it should.

If you are interested, have any questions, or are missing a feature, or just 
find any bugs, please, just let me know.

Changing the configuration and sighuping the application perform send the peers 
the correct update messages to change the peer RIB.
Or just enable graceful-restart and restart the application if you do not care 
about the number of update :p

More information:
- http://www.terena.org/activities/tf-ngn/tf-ngn17/uze-flowspec.pdf
- 
http://resources.nznog.org/2006/Friday-240306/DavidLambert-BGPFlowSpecificationUpdate/Lambert.ppt
- http://uknof.org/uknof15/Mangin-NakedBGP.pdf (another shameless selfplug - 
BGP overview - 3 slides on FlowSpec)

Thomas
--
Exa Networks Limited - http://www.exa-networks.co.uk/
Company No. 04922037 - VAT no. 829 1565 09
27-29 Mill Field Road, BD16 1PY, UK
Phone: +44 (0) 845 145 1234 - Fax: +44 (0) 1274 567646

-

neighbor 82.219.123.221 {
 [] 
 flow {
 route {
 match {
 source 10.0.0.1/32;
 destination 192.168.0.1/32;
 port =80;
 destination-port =3128 >8080&<8088;
 source-port >1024;
 protocol tcp;
#   protocol [ tcp udp ];
#   packet-length >200&<300 >400&<500;
#   fragment not-a-fragment;
#   fragment [ first-fragment last-fragment ];
#   icmp-type [ unreachable echo-request echo-reply ];
#   icmp-code [ host-unreachable network-unreachable ];
#   tcp-flags [ urgent rst ];
#   dscp [ 10 20 ];

 }
 then {
 discard;
#   rate-limit 9600;
#   redirect 65500:12345;
#   redirect 1.2.3.4:5678;
 }
 }
 }
}


thomas.man...@m7i-4.u3.tcw.uk> show configuration logical-routers trap 
protocols bgp 
local-as 30740;
group flow {
 type external;
 multihop;
 local-preference 100;
 local-address 82.219.123.221;
 import no-export;
 export deny-all;
 peer-as 65500;
 neighbor 82.219.131.242 {
 traceoptions {
 file bgp;
 flag all;
 }
 family inet {
 unicast;
 flow {
 no-validate everything;
 }
 }
 family inet6 {
 unicast;
 }
 }
}

thomas.man...@m7i-4.u3.tcw.uk> show configuration logical-routers trap 
policy-options policy-statement everything   
then accept;

# env PYTHONPATH=~/source/bgp/lib/ python daemon/bgpd etc/bgp/m7i-service.txt 
033 12:28:13  Supervisor/performing reload
033 12:28:13  Supervisor/New Peer 82.219.123.221
033 12:28:1482.219.123.221/  30740 -> OPEN version=4 asn=65500 
hold_time=180 router_id=82.219.131.242 capabilities=[Graceful Restart Flags 0x8 
Time 5 IPv4/flow-ipv4=0x80 IPv4/unicast=0x80 IPv6/unicast=0x80, Multiprotocol 
IPv4 unicast IPv6 unicast IPv4 flow-ipv4]
033 12:28:1582.219.123.221/  30740 <- OPEN version=4 asn=30740 hold_time=90 
router_id=82.219.123.221 capabilities=[Cisco Route Refresh (unparsed), 
Multiprotocol IPv4 unicast IPv6 unicast IPv4 flow-ipv4, Route Refresh 
(unparsed)]
033 12:28:1682.219.123.221/  30740 -> KEEPALIVE
033 12:28:1782.219.123.221/  30740 <- KEEPALIVE
announcing IPv6 unicast 2a02:b80:0:6:50::1/128 next-hop 
2a02:b80::90:0:52e:0:1 med 100
announcing IPv4 flow-ipv4 destination 192.168.0.1/32,source 
10.0.0.1/32,protocol =TCP,port =80,destination-port =3128 
>8080&<8088,source-port >1024 extended community [ 0x80 0x6 0x0 0x0 0x0 0x0 0x0 
0x0 ]
announcing IPv4 unicast 82.219.4.100/32 next-hop 82.219.4.101 med 100
033 12:28:1782.219.123.221/  30740 -> UPDATE (3)
033 12:28:1782.219.123.221/  30740 <- KEEPALIVE

thomas.man...@m7i-4.u3.tcw.uk> show route logical-router trap table inetflow.0 
extensive 

inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
192.168.0.1,10.0.0.1,proto=6,port=80,dstport=3128,>8080&<8088,srcport>1024/256 
(1 entry, 0 announced)
 *BGPPreference: 170/-101
 Next hop type: Fictitious
   

Re: BGP FlowSpec support on provider networks

[sthaug]

> Now I realize that FlowSpec isn't a panacea, but it certainly meets some
> of the requirements that many customers have today, and it gives us a
> lot more flexibility over simply destination based filtering.  Whether
> it's FlowSpec or something else, what's it going to take to get the
> vendors and the providers to start moving forward on technologies that
> are way overdue given the current trend of worms, botnets, and other
> Internet nastiness?

Well, pretty clearly it's going to have to be multivendor, and not IPR
encumbered. Aside from that, of course, the usual advice is to talk to
your SE and vote with your wallet.

>From our point of view, BGP triggered destination-based filtering is
still one of our most important tools. We have thought about FlowSpec
but haven't felt the need sufficiently strongly. Due to M&A we are now
moving to a mixed Cisco/Juniper network - and FlowSpec is no longer
all that interesting since Cisco doesn't implement it.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

RE: BGP FlowSpec support on provider networks

[Fouant, Stefan]

> -Original Message-
> From: Jared Mauch [mailto:ja...@puck.nether.net]
> >> Can you name 3 major vendors who support it?  I suspect more
> >> providers would
> >
> > juniper... and when they dropped the IPR stuff other vendors
> basically
> > walked away :(
> 
> Causing consultations with lawyers by others involved with the draft.
> Life is interesting.
> 
> IPR, Politics and techie communication skills.  The path to failure.

I am familiar with the situation with the IPR and I have to say it's a
very disappointing turn of events.  I've long held Juniper in high
regard as a leader in innovation, but in this instance I feel their
actions are doing quite the opposite.

That aside, it's 2009 and we're still left with a situation where
methodologies which have been used for roughly a decade now (i.e. BGP
triggered destination-based filtering) is still considered the norm.
Now I realize that FlowSpec isn't a panacea, but it certainly meets some
of the requirements that many customers have today, and it gives us a
lot more flexibility over simply destination based filtering.  Whether
it's FlowSpec or something else, what's it going to take to get the
vendors and the providers to start moving forward on technologies that
are way overdue given the current trend of worms, botnets, and other
Internet nastiness?

Stefan Fouant: NeuStar, Inc.
Principal Network Engineer 
46000 Center Oak Plaza Sterling, VA 20166
[ T ] +1 571 434 5656 [ M ] +1 202 210 2075
[ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz

Re: BGP FlowSpec support on provider networks

[Jared Mauch]

On Apr 11, 2009, at 12:54 AM, Christopher Morrow wrote:

On Fri, Apr 10, 2009 at 6:38 PM, John Payne   
wrote:



On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" >

wrote:


Hi folks,

I am trying to compile data on which providers are currently  
supporting
BGP Flowspec at their edge, if there are any at all.  The few  
providers
I've reached out to have indicated they do not support this and  
have no

intention of supporting this any time in the near future.  I'm also
curious why something so useful as to have the ability to  
advertise flow
specification information in NLRI and distribute filtering  
information

is taking so long to gain a foothold in the industry...


Can you name 3 major vendors who support it?  I suspect more  
providers would


juniper... and when they dropped the IPR stuff other vendors basically
walked away :(


Causing consultations with lawyers by others involved with the draft.   
Life is interesting.


IPR, Politics and techie communication skills.  The path to failure.

- Jared

Re: BGP FlowSpec support on provider networks

[Christopher Morrow]

On Fri, Apr 10, 2009 at 6:38 PM, John Payne  wrote:
>
>
> On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" 
> wrote:
>
>> Hi folks,
>>
>> I am trying to compile data on which providers are currently supporting
>> BGP Flowspec at their edge, if there are any at all.  The few providers
>> I've reached out to have indicated they do not support this and have no
>> intention of supporting this any time in the near future.  I'm also
>> curious why something so useful as to have the ability to advertise flow
>> specification information in NLRI and distribute filtering information
>> is taking so long to gain a foothold in the industry...
>
> Can you name 3 major vendors who support it?  I suspect more providers would

juniper... and when they dropped the IPR stuff other vendors basically
walked away :(

> offer it if there was vendor support.
> Last I checked, at least one vendor was fighting mad over the thought of
> supporting it.

yes :( weee! poilitics!

>
>

Re: BGP FlowSpec support on provider networks

[Richard A Steenbergen]

> I am trying to compile data on which providers are currently
> supporting BGP Flowspec at their edge, if there are any at all.  The
> few providers I've reached out to have indicated they do not support
> this and have no intention of supporting this any time in the near
> future.  I'm also curious why something so useful as to have the
> ability to advertise flow specification information in NLRI and
> distribute filtering information is taking so long to gain a foothold
> in the industry...


nLayer has offered flowspec support to customers for many years now.


It's really quite simple to use and support too, if you happen to have a
largely Juniper based network that is. I'm not aware of any other router
vendor who currently supports it, but the loss is entirely theirs.

We do have a fair bit of Crisco in the network, with Juniper primarily
in the core and peering/transit edge, so we use a route-server to feed
the flowspec routes into the Juniper core. Customers set up an ebgp
multihop session with it, and can announce flowspec routes (or standard
blackhole via bgp communities) for anything in their register
prefix-list. It's also quite handy for distributing internal use packet
filters too.

As for why something so (insanely) useful is slow to be adopted... There 
are a few reasons, but mostly:

1) A healthy dose of inter-vendor politics.

2) A silly religious belief that bgp shouldn't be used to carry firewall
information, and that some other protocol should be invented instead. I
think the counter-argument to that is the ability to do inter-provider
filtering is precisely why it should be done via bgp. and the success of
the current implementation proves how well it works.

3) Another large network who shall remain nameless once used a third
party flowspec speaking piece of software which shall also remain
nameless, and managed to blackhole their entire network for a noticeable
amount of time. As with anything combining the words "network wide
protocol" and "packet filter", a healthy amount of user discretion is
advised.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: BGP FlowSpec support on provider networks

[McDonald Richards]

In my experience it's vendor support that is lacking, not provider
support



On Sat, Apr 11, 2009 at 6:08 AM, Fouant, Stefan
wrote:

> Hi folks,
>
> I am trying to compile data on which providers are currently supporting
> BGP Flowspec at their edge, if there are any at all.  The few providers
> I've reached out to have indicated they do not support this and have no
> intention of supporting this any time in the near future.  I'm also
> curious why something so useful as to have the ability to advertise flow
> specification information in NLRI and distribute filtering information
> is taking so long to gain a foothold in the industry...
>
> Stefan Fouant: NeuStar, Inc.
> Principal Network Engineer
> 46000 Center Oak Plaza Sterling, VA 20166
> [ T ] +1 571 434 5656 [ M ] +1 202 210 2075
> [ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz
>
>

Re: BGP FlowSpec support on provider networks

[John Payne]

On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan"  
 wrote:



Hi folks,

I am trying to compile data on which providers are currently  
supporting
BGP Flowspec at their edge, if there are any at all.  The few  
providers
I've reached out to have indicated they do not support this and have  
no

intention of supporting this any time in the near future.  I'm also
curious why something so useful as to have the ability to advertise  
flow

specification information in NLRI and distribute filtering information
is taking so long to gain a foothold in the industry...


Can you name 3 major vendors who support it?  I suspect more providers  
would offer it if there was vendor support.
Last I checked, at least one vendor was fighting mad over the thought  
of supporting it.

Re: BGP FlowSpec support on provider networks

[Charles Wyble]

Fouant, Stefan wrote:

Hi folks,

I am trying to compile data on which providers are currently supporting
BGP Flowspec at their edge, if there are any at all.  The few providers
I've reached out to have indicated they do not support this and have no
intention of supporting this any time in the near future.  I'm also
curious why something so useful as to have the ability to advertise flow
specification information in NLRI and distribute filtering information
is taking so long to gain a foothold in the industry... 



See ipv6 :)

BGP FlowSpec support on provider networks

[Fouant, Stefan]

Hi folks,

I am trying to compile data on which providers are currently supporting
BGP Flowspec at their edge, if there are any at all.  The few providers
I've reached out to have indicated they do not support this and have no
intention of supporting this any time in the near future.  I'm also
curious why something so useful as to have the ability to advertise flow
specification information in NLRI and distribute filtering information
is taking so long to gain a foothold in the industry...

Sorry for the repost but wanted to make sure this got it's own thread.
Thanks,

Stefan Fouant: NeuStar, Inc.
Principal Network Engineer 
46000 Center Oak Plaza Sterling, VA 20166
[ T ] +1 571 434 5656 [ M ] +1 202 210 2075
[ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz

Re: BGP FlowSpec support on provider networks

[Seth Mattinen]

Fouant, Stefan wrote:
> Hi folks,
> 
> I am trying to compile data on which providers are currently supporting
> BGP Flowspec at their edge, if there are any at all.  The few providers
> I've reached out to have indicated they do not support this and have no
> intention of supporting this any time in the near future.  I'm also
> curious why something so useful as to have the ability to advertise flow
> specification information in NLRI and distribute filtering information
> is taking so long to gain a foothold in the industry... 
> 

Just FYI, but when you hit reply and change the subject, your message
still shows up under the "Fiber cut in SF area" thread. Anyone who's
ignoring that thread will not see your message.

~Seth

BGP FlowSpec support on provider networks

[Fouant, Stefan]

Hi folks,

I am trying to compile data on which providers are currently supporting
BGP Flowspec at their edge, if there are any at all.  The few providers
I've reached out to have indicated they do not support this and have no
intention of supporting this any time in the near future.  I'm also
curious why something so useful as to have the ability to advertise flow
specification information in NLRI and distribute filtering information
is taking so long to gain a foothold in the industry... 

Stefan Fouant: NeuStar, Inc.
Principal Network Engineer 
46000 Center Oak Plaza Sterling, VA 20166
[ T ] +1 571 434 5656 [ M ] +1 202 210 2075
[ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz