Hi Shawn, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Benjamin Kaduk [mailto:kaduk@xxxxxxx] > Envoyé : dimanche 7 juin 2020 02:05 > À : Shawn Emery > Cc : secdir; draft-ietf-dots-signal-filter-control.all@xxxxxxxx; last- > call@xxxxxxxx; Shawn Emery > Objet : Re: Review of draft-ietf-dots-signal-filter-control-04 > > Hi Shawn, > > Thanks for the review. > I believe you're correct that any filter that filters monitoring > agents > would have to have been confiugred previously over the data channel, > yes. > > -Ben > > On Fri, Jun 05, 2020 at 04:14:02PM -0600, Shawn Emery wrote: > > Reviewer: Shawn M. Emery > > Review result: Ready with nits > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > IESG. > > These comments were written primarily for the benefit of the > security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This draft specifies a filter control through the Distributed > > Denial-of-Service Open Threat > > Signaling (DOTS) signal channel rather than through the data > channel, given > > that an active > > DDoS attack would essentially disable the data channel. The > assumption is > > that the filter > > rules would have been constructed and distributed during idle time, > before > > the attack. > > > > The security considerations section does exist and the defers to the > base > > RFCs, 8782 and 8783, for confidentiality and integrity requirements. > The > > draft > > continues that the filtering rules should be constructed before any > attack > > through > > the data channel. The section finishes with an attack by using the > control > > filter to > > make a DDoS worse and recommends mitigation through operators > monitoring > > and countering malicious behavior. They describe this as only a > variation > > of the > > attacks outlined in 8782 and 8783, though I wonder if a new attack > vector is > > introduced through an attacker enabling a filter that filters > monitoring > > agents? > > However this would have had to have been configured through the data > channel > > priori, no? [Med] I confirm. > > > > General comments: > > > > Thank you for the examples, this makes the concepts behind the draft > more > > clear. > > > > Editorial comments: > > > > ietf-dots-signal-channel and ietf-dots-data-channel are now RFCs. > > [Med] Fixed in our local copy. Thanks. > > Shawn. > > -- -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
