Subject: [Sdn] new draft on SDN for DDoS mitigation

From: Wesley Eddy <[email-masked]>
Date: Wed, 12 Aug 2015 09:16:42 -0400

Hello, we wanted to make people aware of a new I-D that uses SDN (or
more specifically OpenFlow) as a tool to improve DDoS mitigation:

https://datatracker.ietf.org/doc/draft-eddy-sdnrg-customer-filters/

The interesting part of this for SDNRG is probably the sub-controller
concept, which is how we allow OpenFlow to be used inter-domain (for
customers to control aspects of their ISP's network), and the three-
stage organization of flow tables.

The content is fairly specific to DDoS, but could be extended and
generalized for other uses.

Much of the other interdomain SDN work has the ISPs setting up virtual
networks for each customer, or slice-based constructions, which are not
required by this sub-controller approach.  It may be of interest as
an alternative construction with its own set of advantages and
disadvantages in comparison to other interdomain SDN approaches.

We're eager to hear your comments, criticisms, and questions.

-- 
Wes Eddy
MTI Systems

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Aug 2015 22:35:12 +0000

Eddy, et al,

I think the content provided by this draft will be very useful in preventing junk and malicious traffic taking over precious network resources and providing a more effective way to protect applications from DoS/DDoS attacks.

A few comments to the draft:

-       When applications or end points (Customer sites) detect any kind of attack and need to inform ISPs to block those traffic,  the packets content might be using private addresses, local Tenant Identifiers, etc, while the filters for the ISP ingress may  be using "public addresses".

-       Figure 1: The Filter Management Apps is from customer side. The "filter rules" or the commands to "ISF Sub-Controller" may need more than what OpenFlow (e.g. OF1.5) can provide because those rules/commands might need to specify the environmental conditions that are not in the packets, e.g. Time of the Day, a specific event, customer ID, etc. Maybe some other methods should be explored, such as Open-Config, or OF-config, or others

-       The requests from applications and end points may be from different administrative domains than the ISP, therefore it is necessary to have pre-agreed format to pass "Filter rules". The recent IETF initiative (Interface to Network Security Functions - I2NSF is intended to specify the standardized format for specifying rules to security functions. See the latest charter: https://sites.google.com/site/interface2nsf/home ). I see your draft provide a really good input to I2NSF.

Linda

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Wednesday, August 12, 2015 8:17 AM
To: [email-masked]
Cc: gclark mti-systems.com; Justin Dailey
Subject: [Sdn] new draft on SDN for DDoS mitigation

Hello, we wanted to make people aware of a new I-D that uses SDN (or more specifically OpenFlow) as a tool to improve DDoS mitigation:

The interesting part of this for SDNRG is probably the sub-controller concept, which is how we allow OpenFlow to be used inter-domain (for customers to control aspects of their ISP's network), and the three- stage organization of flow tables.

The content is fairly specific to DDoS, but could be extended and generalized for other uses.

Much of the other interdomain SDN work has the ISPs setting up virtual networks for each customer, or slice-based constructions, which are not required by this sub-controller approach.  It may be of interest as an alternative construction with its own set of advantages and disadvantages in comparison to other interdomain SDN approaches.

--
Wes Eddy
MTI Systems

_______________________________________________
sdn mailing list
[email-masked]<mailto:[email-masked]>
https://mail.ietf.org/mailman/listinfo/sdn

---

From: Patrick Lismore <[email-masked]>
Date: Thu, 27 Aug 2015 15:58:37 +0100

Hello everyone,

I have been reading the emails for this list for a while and wanted to
contribute.

My research this year as part of my MSc was on Threat Mitigation & Digital
Forensics in Software Defined Networks.

I have never contributed to IETF before but would like to get more involved
with the SDNRG.

What is the best way to engage?

Should I help some contributors with their research?, submit a paper or
throw out some ideas.

best regards

Patrick Lismore
@patricklismore

On Wed, Aug 12, 2015 at 2:16 PM, Wesley Eddy <[email-masked]> wrote:

> [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 27 Aug 2015 12:08:21 -0400

On 8/26/2015 6:35 PM, Linda Dunbar wrote:
> Eddy, et al,
>  
> I think the content provided by this draft will be very useful in
> preventing junk and malicious traffic taking over precious network
> resources and providing a more effective way to protect applications
> from DoS/DDoS attacks.

Hi Linda, thank you for the insightful comments.  My thoughts on each
of them are enclosed below:

> 
>   * When applications or end points (Customer sites) detect any kind of
>     attack and need to inform ISPs to block those traffic, the packets
>     content might be using private addresses, local Tenant Identifiers,
>     etc, while the filters for the ISP ingress may be using "public
>     addresses". 

This is a good point.  We had not been deeply considering cases beyond
"normal" end sites with their own routable prefixes.  However, the
situations you note are probably more normal in actuality today.  It
should be possible for any party with knowledge of an address mapping
to perform that mapping on destination address (or prefix) fields in
the filter definitions, but we had not thought about where this fits
in yet.  It sounds like a good topic to address in an update.

>   * Figure 1: The Filter Management Apps is from customer side. The
>     "filter rules" or the commands to "ISF Sub-Controller" may need more
>     than what OpenFlow (e.g. OF1.5) can provide because those
>     rules/commands might need to specify the environmental conditions
>     that are not in the packets, e.g. Time of the Day, a specific event,
>     customer ID, etc. Maybe some other methods should be explored, such
>     as Open-Config, or OF-config, or others

This is possible, though my assumption is that the same effect can be
obtained in software logic in the customer network, without additional
protocols needed to be used interdomain (or adapted for interdomain
use).  I would be interested in talking more about this to understand
if the cases where it would be necessary.

>   * The requests from applications and end points may be from different
>     administrative domains than the ISP, therefore it is necessary to
>     have pre-agreed format to pass "Filter rules". The recent IETF
>     initiative (Interface to Network Security Functions - I2NSF is
>     intended to specify the standardized format for specifying rules to
>     security functions. See the latest charter:
>     _https://sites.google.com/site/interface2nsf/home_ ). I see your
>     draft provide a really good input to I2NSF. 

I agree, thanks for pointing it out!

-- 
Wes Eddy
MTI Systems

---

From: "King, Daniel" <[email-masked]>
Date: Fri, 28 Aug 2015 09:05:05 +0000

Hi Patrick,

All IRTF/IETF participation is very welcome!

There are often differences between contributing to an IRTF Research Group (RG) and an IETF Working Group (WG). In the SDN RG we tend to encourage initial discussion via the SDN mailing list or an RG presentation to aid formulation of the research challenge and setting context and/or scope, rather than the typical IETF approach of submitting a 00 Internet-Draft (I-D). Then if the topic/work merits further investigation an Internet-Draft would be a fine way forward.

If you followed the recent SDN RG session at IETF 93 we had a dedicated session on SDN Security:

https://www.ietf.org/proceedings/93/agenda/agenda-93-sdnrg

Identifying a few SDN use cases and subsequent Security requirements would be a great way to help initiate and steer SDN RG list discussion. A reasonable output could then be an SDN Security I-D that summarises the challenges and available methods/technologies for mitigating Security risks and issues. The I-D could also identify gaps and possible candidate solutions via existing IETF WG protocols and mechanisms, recent WG proposals, or indeed the need for something entirely new (seeding a bar-BOF, further discussions, etc.).

BR, Dan.

From: sdn [mailto:[email-masked]] On Behalf Of Patrick Lismore
Sent: 27 August 2015 15:59
Cc: [email-masked]
Subject: Re: [Sdn] new draft on SDN for DDoS mitigation

Hello everyone,

I have been reading the emails for this list for a while and wanted to contribute.

My research this year as part of my MSc was on Threat Mitigation & Digital Forensics in Software Defined Networks.

I have never contributed to IETF before but would like to get more involved with the SDNRG.

Should I help some contributors with their research?, submit a paper or throw out some ideas.

best regards

Patrick Lismore
@patricklismore

On Wed, Aug 12, 2015 at 2:16 PM, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:
Hello, we wanted to make people aware of a new I-D that uses SDN (or
more specifically OpenFlow) as a tool to improve DDoS mitigation:

--
Wes Eddy
MTI Systems

---

From: Ali Haider <[email-masked]>
Date: Fri, 28 Aug 2015 14:58:00 +0500

This was an interesting read.

​It may be out of context for the filtering system (or it may not be)
however, some kind of a weighted mechanism can be implemented in order to
reduce the effect of temporary fluctuations or changes in the traffic.
Since these changes do not last long, they must be ignored and filtering
rules should not be installed for these.​ Otherwise, rules will be
installed only to be removed moments later.

Just a thought.

-- 
*​Syed Ali Haider*, Ph.D
​Assistant Professor
School of Electrical Engineering and Computer Science
National University of Sciences ​and​ Technology
Sector H-12, Islamabad, Pakistan
​t: +92 51 90852109
​e: [email-masked]​
- - - - - - - - - - - - - - - - - - - - -