Subject: [Dots] Opsdir last call review of draft-ietf-dots-signal-filter-control-04

From: Tim Chown via Datatracker <[email-masked]>
Date: Mon, 15 Jun 2020 08:08:29 -0700

Reviewer: Tim Chown
Review result: Has Nits

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document is one of a set of documents produced by the DDoS Open Threat
Signalling (DOTS) working group, and builds on previously published RFCs (RFC
8782, 8783). It describes a mechanism by which the DOTS signalling channel
defined in RFC 8782 can be used to allow a DOTS client that is under attack to
change the filtering rules and thus the mitigation behaviour being applied to
it via a DOTS server, even when the downstream to it may be saturated.

The text is well-written with a good structure and a healthy number of
examples. I would asses its current state as Ready with Nits.  The new
capability seems very useful.

General comments:

I am not wholly clear about some terms, e.g. “idle time” seems to be when no
mitigation is in place, but does this mean no filtering rules are active, or no
anti-DDoS rules are active?  Or are all DOTS rules there for mitigation rather
than general protection?

If I understand correctly, this extension allows new filter rules to be added,
such as rate limits, so it’s not just that the signal channel can be used to
control (activate and deactivate) existing filters.  If correct, perhaps that
could be made more explicit early on, even in the abstract.

Section 1.1:

The problem statement is good.  A very clear requirement.

Section 1.2:

I would add some text that briefly explains the different properties of RFC
8782 and 8783, i.e. that with its lightweight design and heartbeat protocol
(section 4.7 of RFC 8782) the signalling channel can be used to communicate
with a DOTS server even when the downstream link to the DOTS client is
saturated.  As it is, you have to be familiar with RFC 8782 to understand
what’s written here; some extra clarity would be useful.

Section 3.2.1:

“A DOTS client relies on information received from the DOTS server…” but can it
always receive such information if the link is saturated?  It seems to me that
you can push messages from client to server under an attack, but cannot assume
the reverse is true?

Nits:

Abstract:

The filtering rules are “supposed to be conveyed during idle time .. by the
data channel” - does that mean they can be conveyed outside quiet time, or MUST
NOT be conveyed outside idle time over the data channel?   Or does the new
capability in this document make that a MUST or SHOULD NOT?

Section 1.1:
What is “the conflict” in para 4?

Otherwise, very clean with no typos that I see.

Best wishes,
Tim

---

From: <[email-masked]>
Date: Tue, 16 Jun 2020 05:51:24 +0000

Hi Tim,

Thank you for the review. Much appreciated. 

A candidate version that takes into account your review is available at: 

https://github.com/boucadair/filter-control/blob/master/draft-ietf-dots-signal-filter-control-05.txt 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Tim Chown via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 15 juin 2020 17:08
> À : [email-masked]
> Cc : [email-masked]; last-
> [email-masked]; [email-masked]
> Objet : Opsdir last call review of draft-ietf-dots-signal-filter-control-04
> 
> Reviewer: Tim Chown
> Review result: Has Nits
> 
> Hi,
> 

[Med] Idle time refers to when there is no active mitigation. This is mentioned in Section 1.1:

   A typical case is a DOTS client which configures during 'idle' time
   (i.e., no mitigation is active) ...

Filtering can be activated even if no mitigation is active. This is controlled by the DOTS client by setting "activation-type" to "immediate".

I updated the abstract as follows:

OLD:
   Particularly, this extension allows a DOTS client to activate or de-
   activate existing filtering rules during a DDoS attack.  The
   characterization of these filtering rules is supposed to be conveyed
   by a DOTS client during an idle time by means of the DOTS data
   channel protocol.

NEW:
   Particularly, this extension allows a DOTS client to activate or de-
   activate existing filtering rules during a DDoS attack.  The
   characterization of these filtering rules is supposed to be conveyed
   by a DOTS client during an idle time (i.e., no mitigation is active)
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   by means of the DOTS data channel protocol.

> control (activate and deactivate) existing filters.

[Med] No, this is not supported. This is now more explicit in Section 1.2 (-05):

   Note that creating these filtering rules is still the responsibility
   of the DOTS data channel [RFC8783]. 

  If correct, perhaps
> that

[Med] I added a new introduction paragraph among these lines. 

> always receive such information if the link is saturated?

[Med] Not always...this is why we have "and/or local information" right after the text you quoted.  

  It seems to me
> that

[Med] Yes. 

> capability in this document make that a MUST or SHOULD NOT?

[Med] When an attack is ongoing, the data channel is likely to be broken. We don't change the behavior in RFC8783.

> What is “the conflict” in para 4?

[Med] This refers to the conflict discussed in the paragraph right before the one you quoted:  

   A typical case is a DOTS client which configures during 'idle' time
   (i.e., no mitigation is active) some filtering rules using the DOTS
   data channel protocol to permit traffic from accept-listed sources,
   but during a volumetric DDoS attack the DDoS mitigator identifies the
   source addresses/prefixes in the accept-listed filtering rules are
   attacking the target.  

I made this change:

OLD:

   A typical case is a DOTS client which configures during 'idle' time
   (i.e., no mitigation is active) some filtering rules using the DOTS
   data channel protocol to permit traffic from accept-listed sources,
   but during a volumetric DDoS attack the DDoS mitigator identifies the
   source addresses/prefixes in the accept-listed filtering rules are
   attacking the target.  For example, an attacker can spoof the IP
   addresses of accept-listed sources to generate attack traffic or the
   attacker can compromise the accept-listed sources and program them to
   launch a DDoS attack.

   [RFC8782] is designed so that the DDoS server notifies the conflict
   to the DOTS client (that is, 'conflict-cause' parameter set to 2
   (Conflicts with an existing accept list)),

NEW:

   A typical case is a conflict between filtering rules installed by a
   DOTS client and the mitigation actions of a DDoS mitigator.  Such
   case is a DOTS client which configures during 'idle' time (i.e., no
   mitigation is active) some filtering rules using the DOTS data
   channel protocol to permit traffic from accept-listed sources, but
   during a volumetric DDoS attack the DDoS mitigator identifies the
   source addresses/prefixes in the accept-listed filtering rules are
   attacking the target.  For example, an attacker can spoof the IP
   addresses of accept-listed sources to generate attack traffic or the
   attacker can compromise the accept-listed sources and program them to
   launch a DDoS attack.

   [RFC8782] is designed so that the DDoS server notifies the above
   conflict to the DOTS client (that is, 'conflict-cause' parameter set
   to 2 (Conflicts with an existing accept list)),

Better? 

> Otherwise, very clean with no typos that I see.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Jun 2020 14:57:18 +0000

Hi,

Some comments on your comments in line….

> On 16 Jun 2020, at 06:51, [email-masked] wrote:
> 
> Hi Tim,
> 

[TC] what would be great is a diff to the version I reviewed.

>   by a DOTS client during an idle time (i.e., no mitigation is active)

[TC] I think the problem (for me) here is I don’t understand how the client knows whether there is active mitigation; does the client have a state stable of which filters it has requested the server to activate?

Is there a difference between filters being active, and mitigation being active?  Are all filters mitigation against a current attack?

>   of the DOTS data channel [RFC8783]. 

[TC]. Ah, thanks.  I misread the example around Figure 9 to think the example was installing the filter when it was only activating it.  Understood now :)

> [Med] I added a new introduction paragraph among these lines. 

[TC] This doesn’t flow as well as it might.

Perhaps change

"The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal
   channel protocol [RFC8782] can be established between two DOTS agents
   prior to or during an attack.  Once the signal channel is
   established, the DOTS agents may periodically send heartbeats to keep
   the channel active (Section 4.7 of [RFC8782]).  At any time, the DOTS
   client may send mitigation requests (Section 4.4 of [RFC8782]) to a
   DOTS server over the active signal channel.  While mitigation is
   active, the DOTS server periodically sends status messages to the
   DOTS client, including basic mitigation feedback details.  In case of
   a massive DDoS attack that saturates the incoming link(s) to the DOTS
   client, all traffic from the DOTS server to the DOTS client will
   likely be dropped, although the DOTS server receives heartbeat
   requests in addition to DOTS messages sent by the DOTS client.

   The DOTS data channel protocol [RFC8783] is used for bulk data
   exchange between DOTS agents to improve the coordination of parties
   involved in the response to a Distributed Denial-of-Service (DDoS)
   attack.  Filter management is one of its tasks which enables a DOTS
   client to retrieve the filtering capabilities of a DOTS server and to
   manage filtering rules.  Typically, these filtering rules are used
   for dropping or rate-limiting unwanted traffic, and permitting
   accept-listed traffic.

   Unlike the DOTS signal channel protocol [RFC8782], the DOTS data
   channel protocol is not expected to deal with attack conditions.  As
   such, an issue that might be encountered in some deployments is when
   filters installed by means of the DOTS data channel protocol may not
   function as expected during DDoS attacks or, worse, exacerbate an
   ongoing DDoS attack.  The DOTS data channel protocol cannot be used
   then to change these filters, which may complicate DDoS mitigation
   operations [Interop].”

to

"The Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture 
includes both a data channel protocol [RFC 8783] and a signal channel protocol 
[RFC8782].

  The DOTS data channel protocol is used for bulk data
   exchange between DOTS agents to improve the coordination of parties
   involved in the response to a Distributed Denial-of-Service (DDoS)
   attack.  Filter management is one of its tasks which enables a DOTS
   client to retrieve the filtering capabilities of a DOTS server and to
   manage filtering rules.  Typically, these filtering rules are used
   for dropping or rate-limiting unwanted traffic, and permitting
   accept-listed traffic.

 The DOTS signal channel protocol [RFC8782] can be established 
between two DOTS agents prior to or during an attack. At any time, the DOTS
   client may send mitigation requests (as per Section 4.4 of [RFC8782]) to a
   DOTS server over the active signal channel.  While mitigation is
   active, the DOTS server periodically sends status messages to the
   DOTS client, including basic mitigation feedback details.  In case of
   a massive DDoS attack that saturates the incoming link(s) to the DOTS
   client, all traffic from the DOTS server to the DOTS client will
   likely be dropped.  However, the DOTS server may still receive DOTS messages 
sent from the DOTS client over the signalling channel thanks to
  the heartbeat requests keeping the channel active (as described in 
Section 4.7 of [RFC8782]). 

Unlike the DOTS signal channel protocol, the DOTS data
   channel protocol is not expected to deal with attack conditions.  As
   such, an issue that might be encountered in some deployments is when
   filters installed by means of the DOTS data channel protocol may not
   function as expected during DDoS attacks or, worse, exacerbate an
   ongoing DDoS attack.  In such conditions the DOTS data channel protocol 
cannot be used to change these filters, which may complicate DDoS mitigation
   operations [Interop]. 

This draft defines an extension to the signal channel protocol that allows
   DOTS clients to control their filtering rules over the signalling channel when an 
attack mitigation is active and the data channel may not be available. ”

Or something like that.

> [Med] Not always...this is why we have "and/or local information" right after the text you quoted.  

[TC]  OK.

>> you can push messages from client to server under an attack, but cannot

[TC] Thanks.

> [Med] When an attack is ongoing, the data channel is likely to be broken. We don't change the behavior in RFC8783.

[TC] So it can be used, but may not work?  

Perhaps just delete “supposed to be” in the abstract?  Or might the client still try to add an extra filter when mitigation is active?

>   to 2 (Conflicts with an existing accept list)),

[TC] Yes, thanks.

Best wishes,
Tim

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 08:06:48 -0700

> [TC] what would be great is a diff to the version I reviewed.

Try
https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-signal-filter-control-04&url2=https://raw.githubusercontent.com/boucadair/filter-control/master/draft-ietf-dots-signal-filter-control-05.txt

-Ben

---

From: <[email-masked]>
Date: Tue, 16 Jun 2020 15:42:02 +0000

Re-, 

Please see inline. 

Cheers,
Med

> De : Tim Chown [mailto:[email-masked]]
> Envoyé : mardi 16 juin 2020 16:57
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: Opsdir last call review of draft-ietf-dots-signal-filter-
> control-04
> 
> Hi,
> 

[Med] Here it is: https://github.com/boucadair/filter-control/blob/master/diff-review-Tim-Chown.pdf 

The changes includes your comments on the proposed new introduction text. 

> >> comments were written with the intent of improving the operational
> aspects
> >> of
> >> defined in RFC 8782 can be used to allow a DOTS client that is under
> attack
> >> to
> >> change the filtering rules and thus the mitigation behaviour being
> applied
> >> to
> >> I am not wholly clear about some terms, e.g. “idle time” seems to be
> when
> >> no
> >> mitigation is in place, but does this mean no filtering rules are
> active,
> >> or no
> > Filtering can be activated even if no mitigation is active. This is
> controlled by the DOTS client by setting "activation-type" to "immediate".
> >
> [TC] I think the problem (for me) here is I don’t understand how the client
> knows whether there is active mitigation;

[Med] Mitigations can be initiated by the client or triggered by a signal loss. In both cases, the client is aware whether a mitigation is ongoing. All these details are supposed to be covered in the base specs. That's said, and for the reader's convenience, we have now a sentence that recalls that a client sends a mitigation request. 

 does the client have a state
> stable of which filters it has requested the server to activate?

[Med] Yes. 

> 
> Is there a difference between filters being active, and mitigation being
> active? 

[Med] Yes. Mitigation is said to be active if there is a mitigation request received from the client or when a pre-configured mitigation is triggered upon signal loss. Filters can be active even if no attack is detected. 

 Are all filters mitigation against a current attack?

[Med] No. see above. 

> >> such as rate limits, so it’s not just that the signal channel can be
> used
> >> to

---

From: Tim Chown <[email-masked]>
Date: Wed, 17 Jun 2020 11:09:34 +0000

Hi Med,

Thanks, I think that answers all my questions and comments.

Best wishes,
Tim

> On 16 Jun 2020, at 16:42, [email-masked] wrote:
> 
> Re-, 
> 
> Please see inline. 
> 
> Cheers,
> Med
>