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

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

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
 Next-hop reference count: 1
 State: 
 Peer AS: 65500
 Age

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