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

[Tim Chown <[e-mail]>]

Hi Med,

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

Best wishes,
Tim

> On 16 Jun 2020, at 16:42, [e-mail] wrote:
> 
> Re-, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Tim Chown [mailto:[e-mail]]
>> Envoyé : mardi 16 juin 2020 16:57
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Objet : Re: Opsdir last call review of draft-ietf-dots-signal-filter-
>> control-04
>> 
>> Hi,
>> 
>> Some comments on your comments in line….
>> 
>>> On 16 Jun 2020, at 06:51, [e-mail] wrote:
>>> 
>>> 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
>> 
>> [TC] what would be great is a diff to the version I reviewed.
>> 
> 
> [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. 
> 
> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Tim Chown via Datatracker [mailto:[e-mail]]
>>>> Envoyé : lundi 15 juin 2020 17:08
>>>> À : [e-mail]
>>>> Cc : [e-mail]; last-
>>>> [e-mail]; [e-mail]
>>>> Objet : Opsdir last call review of draft-ietf-dots-signal-filter-
>> control-04
>>>> 
>>>> 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?
>>> 
>>> [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.
>> 
>> [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. 
> 
>> 
>>>> 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.
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>