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: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. > > 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. [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 > 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. [Med] I added a new introduction paragraph among these lines. > > 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? [Med] Not always...this is why we have "and/or local information" right after the text you quoted. It seems to me > that > you can push messages from client to server under an attack, but cannot > assume > the reverse is true? > [Med] Yes. > 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? > [Med] When an attack is ongoing, the data channel is likely to be broken. We don't change the behavior in RFC8783. > Section 1.1: > 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. > > Best wishes, > Tim > _________________________________________________________________________________________________________________________ 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
