Subject: Re: [Dots] use of SDN for DDoS mitigation

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Sep 2015 17:10:42 -0400

On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy <[email-masked]> wrote:
> This is not strictly within the scope of the DOTS charter, but
> because it's related to DDoS mitigation, we thought it might
> be of interest to the DOTS list.
>
> This draft was posted to the SDNRG, and discusses use of OpenFlow
> interdomain, for delegating control of ISP network filtering to
> customers:

Folk might consider looking at the prior-art in this arena...
specifically N-Layer's use of flow-spec from customers, and the fairly
well published failure modes of same.

'Let your customer traffic engineer your network!' (no, don't do that)
'Let your customer consume valuable resources on devices in your
network to which they have no ideas about limits of' (no, don't do
that)

> https://datatracker.ietf.org/doc/draft-eddy-sdnrg-customer-filters/
>
> We're eager to hear your comments, criticisms, and questions, but I
> assume that the DOTS chairs would like this to be offlist (or on the
> SDNRG list) since it is not really in-scope for DOTS and might be a
> distraction from the chartered work.
>
> --
> Wes Eddy
> MTI Systems
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 9 Sep 2015 09:25:28 -0400

> well published failure modes of same.

Hi Christopher, thanks for your comments.  We are also doing some
research on improvements to the BGP flowspec capability that you might
be interested in:
https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00

This doesn't directly answer to the implementation problems referenced
above, but those seem like software issues more than protocol failings.

> network to which they have no ideas about limits of' (no, don't do

On this, we fully agree, and in fact our approach is to keep the ISPs
in full control of their own networks, and to only allow customers to
control a limited amount of flow table resources, for filtering only,
and those are sandwiched between ingress and egress flow table chains
that the ISP retains full control of (and are not made visible to the
customers).

Any comments you have on that approach would be really interesting to
us.  We think it might meet your requirement of keeping the customer
from trying to engineer the provider's network or chew up resources.
If this isn't of interest to the rest of DOTS, the chairs can kick us
off-list, and we won't be offended.

-- 
Wes Eddy
MTI Systems

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 20:37:46 +0700

> off-list, and we won't be offended.

It's of general interest, but not directly relevant, IMHO.  We're 
focusing on signaling to initiate DDoS mitigation, not on actual 
mitigation mechanisms; that's what happens post-signaling.

Still good info for folks to know.  I personally think 
draft-eddy-idr-flowspec-exp-00 is a welcome set of enhancements to 
flowspec, and strongly support this work.

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

---

From: Ida Leung <[email-masked]>
Date: Thu, 10 Sep 2015 15:34:00 -0400

Wes,

Just one comment about delegate the control of filters to customer.
Routers today have limitation of how many flowspec routes they can handle
(which is not very big number).   Should there be something in the proposed
draft feedback session can do to make sure not crash to the limit?  I never
do any scale test in my lab and I don't know what happen if the limit of
flowspec routes exceed.  But that is my biggest worryto delegate the
control besides customer make  mistakes on the filter.

...Ida

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 11 Sep 2015 02:38:17 +0700

On 11 Sep 2015, at 2:34, Ida Leung wrote:

> Should there be something in the proposed draft feedback session can 
> do to make sure not crash to the limit?

DOTS doesn't involve sending flowspec routes directly to network 
infrastructure.

Resource management is a function of the mitigation infrastructure and 
systems of the mitigating organization, it's entirely abstracted from 
whatever actual mitigation steps/mechanisms are employed by the 
mitigating organization (though we should support optional generic 
requested-action verb primitives, it's up to the mitigating 
organization's infrastructure/systems as to whether/how to honor them).

This is all beyond the scope for DOTS; it will be mentioned in the 
use-cases draft as a consideration for mitigating organizations.

---

From: Ida Leung <[email-masked]>
Date: Thu, 10 Sep 2015 15:49:01 -0400

Ops. should just reply to Wes for the comment of the flowspec draft.  Not
this DOTS mailing list.

On Thu, Sep 10, 2015 at 3:38 PM, Roland Dobbins <[email-masked]> wrote:

> Should there be something in the proposed draft feedback session can do to
>> make sure not crash to the limit?
>>
>
> whatever actual mitigation steps/mechanisms are employed by the mitigating
> organization (though we should support optional generic requested-action
> verb primitives, it's up to the mitigating organization's
> infrastructure/systems as to whether/how to honor them).
>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Sep 2015 16:40:18 -0400

On 09/10/2015 03:34 PM, Ida Leung wrote:
> Routers today have limitation of how many flowspec routes they can 
> handle (which is not very big number). Should there be something in 
> the proposed draft feedback session can do to make sure not crash to 
> the limit?  I never do any scale test in my lab and I don't know what 
> happen if the limit of flowspec routes exceed.  But that is my biggest 
> worryto delegate the control besides customer make  mistakes on the 
> filter.

Today's limit is tomorrow recommended minimum.  Only where there is some 
hard limit like how much can be transmitted in a set time does this make 
sense.  The later I see a lot in designing of wireless and industrial 
control protocols where you count the microseconds and bits.

>
> ...Ida
>
> On Wed, Sep 9, 2015 at 9:25 AM, Wesley Eddy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>