Subject: [Dots] Filter usage

From: "Jon Shallow" <[email-masked]>
Date: Fri, 29 Dec 2017 15:50:43 -0000

Hi WG,

Should a mitigation request be able to define which filters to use?

This has been raised in the past but there was no real closure - but other
related things did get fixed.

An ACL can comprise of a src/dest IP prefix, port etc. and an action - drop,
allow or rate-limit.

A Filter definition can contain multiple ACLs - the ACLs are now orderable.

An individual DOTS client can now define multiple Filters - the Filters are
now orderable.

However, today, when a mitigation request comes into the DOTS server, all
the Filter rules associated with a DOTS client are taken and passed over to
a DOTS mitigation (how etc. out of scope of DOTS, as well as what the
mitigator does with them is out of scope).

The primary use of the Filters would be for White / Black listed IPs (the
src IP prefix and action defined in an ACL) and there is an implied
assumption that the DOTS mitigator would only apply these White / Black
lists to the IPs that are to be mitigated (i.e. an implicit dest IP prefix
is defined / added in).  These White / Black lists would tend to be fairly
static and normally would be updated during peace time.

However, by using draft-ietf-netconf-acl-model as the basis for these
filters adds in the potential for intelligent DOTS clients to come up with
specific ACLs and hence filters which could be used as hints for the DOTS
mitigator.  The different filters can easily be created / deleted during
peace time - but if an attack is ongoing, a DOTS client may not be able to
update the current set of Filters.  This therefore potentially limits
potential use of special filters (which potentially needing updating as an
attack morphs) matching the current attack characteristics.

There is one camp that thinks that Filters (other than black/white lists)
should not be supported (for a variety of reasons - e.g. DOTS is not to
reproduce FlowSpec, complexity and numbers of ACLs will overwhelm the
infrastructure etc.) as well as the other camp who like the possibility of
flexibility, and in addition say the numbers of ACLs will not be that much
different from the black/white list requirements.

To provide this full flexibility, a mitigation request over the signal
channel needs to be able to specify an array of Filters (in the same way
that an array of Alias-names is specified) to use - thereby being able to
select out of a pre-attack configured set Filters which ones to use.  This
would be an update the signal mitigation requirements.

Comments welcome.

Regards

Jon