Hi Med, Thanks, I think that answers all my questions and comments. Best wishes, Tim > On 16 Jun 2020, at 16:42, mohamed.boucadair@xxxxxxxxxx wrote: > > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Tim Chown [mailto:Tim.Chown@xxxxxxxxxx] >> Envoyé : mardi 16 juin 2020 16:57 >> À : BOUCADAIR Mohamed TGI/OLN >> Cc : ops-dir@xxxxxxxx; draft-ietf-dots-signal-filter-control.all@xxxxxxxx; >> last-call@xxxxxxxx; dots@xxxxxxxx >> 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, mohamed.boucadair@xxxxxxxxxx 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:noreply@xxxxxxxx] >>>> Envoyé : lundi 15 juin 2020 17:08 >>>> À : ops-dir@xxxxxxxx >>>> Cc : draft-ietf-dots-signal-filter-control.all@xxxxxxxx; last- >>>> call@xxxxxxxx; dots@xxxxxxxx >>>> 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. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
