Hi Lishan,
I would say that the requirement relative to an I2NSF controller is
one of translation, and we see this close analogy in SDN.
The reality of network-based security is that it resolves into two
responses: providing visibility to a security event, and performing a
forwarding based enforcement. In my view, one of the things we are
aiding in accomplishing is the decoupling of network security in a
similar fashion to SDN. One of the challenges that SDN continues to
face is the the control data plane interface (CDPI) between the
controller and the switch, in an effort to be declarative, is tightly
defined to the point of being limited. For example, all OpenFlow
switches (OpenFlow being the CDPI) commoditize into the same limited
set of capabilities.
Where this may be a disadvantage in networking, being declarative is a
plus for security. It would be a good thing if we know that
enforcement via packet forwarding is performed in a consistent
fashion, regardless of the NSF triggering the enforcement. In the
case of analytical DDoS, we are currently talking about BGP FlowSpec
(RFC 5575/7674) and Remotely Triggered BlackHole (RTBH - RFC 5635).
In the near future, I anticipate the DOTS WG efforts will be adopted,
but for now Analytical DDoS relies heavily on what I call 'BGP
tricks'. In this case, the I2NSF controller would receive BGP
FlowSpec from analytical DDoS engines and translate it such that the
enforcement forwarding planes would understand. It is the
controller's general role to decouple data received from NSFs, and
translate it into actions that can be enforced.
You are correct in that analytical use of DDoS BGP FlowSpec + RTBH, or
DOTS tomorrow, does not require an I2NSF controller to work today.
But to fully decouple network security in general (including DDoS)
will require a controller function between NSFs and packet forwarding
engines.
Thanks!
Ed Lopez
On 9/27/2016 at 4:52 AM, "Lishan Li" wrote:Dear all,
I have review the use case draft and have the following questions.
Looking forward to your reply.
In the section 3.1.9, it is described that the mechanism to accept
external alerts to trigger automatic configuration change is needed.
In addition, the DDoS mitigation is taken as a example.
However, in general, the automatic DDoS traffic scrubbing system is
composed of two part: a) the traffic monitoring part for the signaling
of the threat;b) DDoS mitigation part. By monitoring the network
alerts, the system willautomatically trigger the defense part for the
traffic scrubbing. So I thinkthat the current system can achieve the
automatic configuration change without the I2NSF controller. This
example is not appropriate to illustratethis use case.
Maybe my understanding is not correct. Looking forward to your
guidance.
Best Regards,Lishan
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
