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. > 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; 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? >> 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]. [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 :) > 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. [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. >> 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. [TC] OK. > > 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. [TC] Thanks. > >> 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. [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? > >> 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? [TC] Yes, thanks. Best wishes, Tim > >> >> 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
