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
