Subject: [Idr] DDoS-Alert BGP Extensions

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

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.

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.

Thank you for your consideration!

Harley Green

bre

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Oct 2015 16:14:44 +0100

Hi Harley,

Thank you for posting your draft.

Let me ask you three basic clarification questions as well as provide three
observations.

Q1:

Today as you know DDoS detection is very often perfomed at dedicated
devices -for example Arbor APSes. Such devices while in data path do not
originate BGP reachability information as such however they already support
RFC5575 to originate filtering information.

Assume that operator keep current model of DDoS detection what NLRI(s) your
new proposed attribute should be injected by APSes into the network ?

Q2:

While having an attribute attached to a prefix may work with PI prefixes I
fail to understand how it would at all work with PA prefixes ? An upstream
AS which owns the PA space will naturally suppress more specifics along
with attached attributes pretty much killing the idea of DDoS mitigation as
close to the attack sources as possible.

Q3:

Even assuming just PI space how are you going to map more then one attack
pattern for a given destination NLRI ? Would combining always all specific
attack vectors into one match be really a good idea ? That question is
specifically questioning the current choice of proposed DDoS-AE Alert
Attribute format.

O1:

You bring number of times reference to CS in the draft. That is a very good
idea however let's point out that all detection devices and/or route
reflectors/route servers can today also peer with RFC5575 to such CS. In
fact dissociation of IP reachability with attack vectors propagation to
such central oracle I would consider more as a positive feature.

O2:

As you point out in section 3.4 alert removal can be done by withdraw or
implicit update. Withdraw is out of the question. Aren't you afraid that by
using implicit IP reachability updates for removal of dynamic DDoS you will
introduce much more of global churn ? Do you have any study if some
implementations with enabled BGP dampening would not apply penalties ?

O3:

With the light of SIDR do you think that increasing dynamics of basic IP
reachability hence loading more crypto processing on routers is a way to go
globally ? IMHO having new SAFI for flow description and actions is a much
cleaner and practical solution.

Many thx,
r.

On Thu, Oct 29, 2015 at 1:41 PM, Harley Green <[email-masked]>
wrote:

> 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.
>
>
>
> 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
> *Harley Green*
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>