Re: [secdir] Review of draft-ietf-dots-signal-filter-control-04

[[e-mail]]

Hi Shawn,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : dimanche 7 juin 2020 02:05
> À : Shawn Emery
> Cc : secdir; [e-mail]; last-
> [e-mail]; 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.
> > --