Subject: Re: [Dots] DDoS-Alert BGP Extensions

From: Stefan Fouant <[email-masked]>
Date: Mon, 26 Oct 2015 15:08:04 +0000

From: Dots <[email-masked]<mailto:[email-masked]>> on behalf of Harley Green <[email-masked]<mailto:[email-masked]>>
Organization: BRE
Date: Thursday, October 22, 2015 at 8:54 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Dots] DDoS-Alert BGP Extensions

Greetings,
I’d like to quickly bring your attention to a new draft called DDoS-AE. The purpose is to leverage the capabilities inherent in most BGP speakers to distribute information about detected DDoS attacks so that these devices can respond to those attacks (throttling/filtering traffic). This new approach overcomes many of the shortcomings of existing standards as it does not require new address types, nor does it require all BGP speakers to support the capability for it to be effective. The target centric approach also serves to leverage existing peering relationships/trust/policies to address concerns of false DDoS Alert announcements. It is primarily an extension to BGP, but because its focus is on DDoS mitigation I wanted to share it with this WG as well.

The draft can be found here: http://datatracker.ietf.org/doc/draft-green-idr-ddosae/

We have performed analytical studies to demonstrate the potential impact of BGP speakers implementing this capability and the results are very promising. I’d be happy to share the study as well as reference implementation (in Quagga) with any interested parties.

Hi Harley,

I finally had a chance to peruse through your draft and here are my initial thoughts. Please note, I am not attempting to start a firestorm or any type of religious debate, but just lend my observations from many years working in and around the service provider community supporting DDoS mitigation efforts.

The core premise as outlined in this draft, as indicated in the Introduction is that "BGP enabled devices are also likely to have the ability to filter and/or throttle traffic; they are also widely distributed throughout networks, making them ideal for mitigating DDoS attacks.”.  While you are correct to surmise that many BGP enabled devices (mostly routers) have the ability to filter and/or throttle traffic, the DDoS problem can not be solved with these mechanisms alone… surely if that was the case this problem would not continue to exist today, or the impact would be much smaller than it is today. Much of the DDoS problem needs to be solved by looking at some semblance of flow state, even if just for a short duration to determine whether flows are legitimate or not. This is not something that routers are very good at and in fact runs counter to their very purpose. So we are left with very simple traffic filtering applications (essentially ACL distribution) and my belief is that BGP Flowspec already does a pretty good job in that regard… on that point it seems that this draft is attempting to supplant some of the very capabilities that are already inherent in Flowspec…

…which leads me to my next point… Flowspec has been around for a long time. And in my daily interactions at almost all of the large tier1/2/3 carriers, I have yet to see many operators implement it. It’s not to say it’s flawed because it’s a brilliant protocol. But in my experience, core network operators really depend on BGP for their core operations and are very reluctant to make any changes in protocol operations because of this dependancy. I understand the BGP-AE protocol extensions are by their very nature optional, but let us look at the penetration of Flowspec to date to get an idea on the likelihood of deployment of such a protocol.

My last thought is that I believe enabling BGP for such means is a fairly heavy price to pay for anything that may want to facilitate the distribution of coordinated DDoS attack mitigation mechamisms. Such might be the case with a Virtual Machine implemented on a hypervisor which would attempt to signal upstream to indicate desire of mitigation services. Should such a VM require implementation of a full BGP stack in order to participate? I would hope not. For this reason alone, I still believe DOTS to be the best protocol for enablement of such coordinated protection mechanisms.

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
Senior Security Engineer
Corero Network Security
Mobile: +1.703.625.6243

---

From: "Harley Green" <[email-masked]>
Date: Thu, 29 Oct 2015 08:21:52 -0400

Hi Stefan,

Thank you for the thoughtful feedback. Your points are well received. I
think that if anything, the points you raise help make the case for why
something like what is in DDoS-AE is needed. 

Just because not all DDoS attacks can be mitigated by any single device or
technology, as of yet, does not necessarily mean that we should not pursue
legitimate options that have the potential to mitigate a large subset of
DDoS and other network attacks. One of the advantages of this BGP based DDoS
Alert system is that devices that are well suited to performing the flow
state monitoring you mention can be used in parallel to existing routers
that specialize in moving packets quickly and performing more simplistic ACL
enforcement. Many tools already exist that could be placed on these more
specialized DDoS detection devices, if not already present, that would allow
them to send their detections as DDoS Alerts through BGP, such as an iBGP
speaker, without being full BGP participants on a core network. 

Once the Alert has been sent into BGP, its propagated like an update to the
prefix that is under attack. This is a unique advantage over flowspec and
other signaling protocols in that many different systems are already setup
to monitor BGP updates, not just routers. This allows routers as well as
other network appliances to see the Alert and implement appropriate filters
to throttle/drop the attack traffic. The DDoS-AE based Alerts would have
wider visibility than flowspec based alerts because they would be
distributed everywhere the update for the prefix would normally go, rather
than stopping at the first BGP speaker that has not negotiated support for
flowspec capabilities. This gives the DDoS-AE based alerts the chance to
reach the widest audience, even reaching BGP monitors that could help
propagate the Alert into other DDoS signaling systems (proprietary or
otherwise). Unlike new signaling protocols it does not require a lot of new
infrastructure in the form of VMs or devices or communications protocols in
order to begin seeing immediate results. Modification of existing BGP
speakers to enable the DDoS-AE BGP extension would be relatively minor,
something that could be included in a regularly scheduled patch.

You are absolutely correct that the large network providers are going to
resist any sort of technology change for security's sake, as they are not in
the business of DDoS mitigation, so much as making sure all traffic gets to
where it is supposed to go as quickly as possible. While these providers
would be the ideal location for implementing the DDoS mitigation mechanisms
(filters/TE), if enough smaller providers and organizations implement the
(filters/TE) then these core providers are still useful in that they support
the DDoS-AE Alert distribution. Even if these core providers know nothing
about DDoS-AE, simply passing the BGP Update message with the DDoS-AE
(optional/transitive) attribute, which they would do as BGP speakers, makes
them facilitators of the mass distribution of these alerts.

I would think that having redundant communication paths for signaling
information about network attacks and coordinating the responses would be
highly desirable. Leveraging existing proprietary systems for vendor
specific devices, DOTS, flowspec, and DDoS-AE would greatly increase the
resiliency of networks to attacks and ensure coordination continues even if
individual systems or protocols fail.

Harley Green

bre

From: Stefan Fouant [mailto:[email-masked]] 
Sent: Monday, October 26, 2015 11:08 AM
To: Harley Green; [email-masked]
Subject: Re: [Dots] DDoS-Alert BGP Extensions

From: Dots <[email-masked]> on behalf of Harley Green
<[email-masked]>
Organization: BRE
Date: Thursday, October 22, 2015 at 8:54 AM
To: "[email-masked]" <[email-masked]>
Subject: [Dots] DDoS-Alert BGP Extensions

Greetings,

I'd like to quickly bring your attention to a new draft called DDoS-AE. The
purpose is to leverage the capabilities inherent in most BGP speakers to
distribute information about detected DDoS attacks so that these devices can
respond to those attacks (throttling/filtering traffic). This new approach
overcomes many of the shortcomings of existing standards as it does not
require new address types, nor does it require all BGP speakers to support
the capability for it to be effective. The target centric approach also
serves to leverage existing peering relationships/trust/policies to address
concerns of false DDoS Alert announcements. It is primarily an extension to
BGP, but because its focus is on DDoS mitigation I wanted to share it with
this WG as well.

The draft can be found here:
http://datatracker.ietf.org/doc/draft-green-idr-ddosae/

We have performed analytical studies to demonstrate the potential impact of
BGP speakers implementing this capability and the results are very
promising. I'd be happy to share the study as well as reference
implementation (in Quagga) with any interested parties.

Hi Harley,

I finally had a chance to peruse through your draft and here are my initial
thoughts. Please note, I am not attempting to start a firestorm or any type
of religious debate, but just lend my observations from many years working
in and around the service provider community supporting DDoS mitigation
efforts.

The core premise as outlined in this draft, as indicated in the Introduction
is that "BGP enabled devices are also likely to have the ability to filter
and/or throttle traffic; they are also widely distributed throughout
networks, making them ideal for mitigating DDoS attacks.".  While you are
correct to surmise that many BGP enabled devices (mostly routers) have the
ability to filter and/or throttle traffic, the DDoS problem can not be
solved with these mechanisms alone. surely if that was the case this problem
would not continue to exist today, or the impact would be much smaller than
it is today. Much of the DDoS problem needs to be solved by looking at some
semblance of flow state, even if just for a short duration to determine
whether flows are legitimate or not. This is not something that routers are
very good at and in fact runs counter to their very purpose. So we are left
with very simple traffic filtering applications (essentially ACL
distribution) and my belief is that BGP Flowspec already does a pretty good
job in that regard. on that point it seems that this draft is attempting to
supplant some of the very capabilities that are already inherent in
Flowspec.

.which leads me to my next point. Flowspec has been around for a long time.
And in my daily interactions at almost all of the large tier1/2/3 carriers,
I have yet to see many operators implement it. It's not to say it's flawed
because it's a brilliant protocol. But in my experience, core network
operators really depend on BGP for their core operations and are very
reluctant to make any changes in protocol operations because of this
dependancy. I understand the BGP-AE protocol extensions are by their very
nature optional, but let us look at the penetration of Flowspec to date to
get an idea on the likelihood of deployment of such a protocol. 

My last thought is that I believe enabling BGP for such means is a fairly
heavy price to pay for anything that may want to facilitate the distribution
of coordinated DDoS attack mitigation mechamisms. Such might be the case
with a Virtual Machine implemented on a hypervisor which would attempt to
signal upstream to indicate desire of mitigation services. Should such a VM
require implementation of a full BGP stack in order to participate? I would
hope not. For this reason alone, I still believe DOTS to be the best
protocol for enablement of such coordinated protection mechanisms.

Stefan Fouant 

Senior Security Engineer

Corero Network Security

Mobile: +1.703.625.6243

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 31 Oct 2015 10:34:26 +0900

On 29 Oct 2015, at 21:21, Harley Green wrote:

> the business of DDoS mitigation,

I've a lot more comments on this draft and will post them later, but I 
would like to point out that *all* the large network providers are in 
the business of DDoS mitigation.

So, I think perhaps it's worth ensuring that everyone engaged in 
thinking about this general space understands that, as it's foundational 
to positing worthwhile innovations in this space.

-----------------------------------
Roland Dobbins <[email-masked]>