Subject: Re: [Dots] Filter usage

From: <[email-masked]>
Date: Wed, 24 Jan 2018 13:28:41 +0000

Hi Jon,

Some comments below:

·         Providing « hints » to the server may be misleading for the server in some cases. This may influence the contractual responsibility engaged by a mitigation providers (e.g., observe long delays to soften an attack because the hint was misleading).

·         A hint is by definition optional, as such it can be defined as a separate extension (if needed). The signal-channel should IMHO focus on the minimum required information to achieve its intended function.

I would not add such feature to the base spec.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : vendredi 29 décembre 2017 16:51
À : [email-masked]
Objet : [Dots] Filter usage

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