Skip to main content

Last Call Review of draft-ietf-dots-signal-filter-control-04
review-ietf-dots-signal-filter-control-04-secdir-lc-emery-2020-06-11-00

Request Review of draft-ietf-dots-signal-filter-control
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-06-15
Requested 2020-06-01
Authors Kaname Nishizuka , Mohamed Boucadair , Tirumaleswar Reddy.K , Takahiko Nagata
Draft last updated 2020-06-11
Completed reviews Opsdir Last Call review of -04 by Tim Chown (diff)
Secdir Last Call review of -04 by Shawn M Emery (diff)
Genart Last Call review of -04 by Christer Holmberg (diff)
Assignment Reviewer Shawn M Emery
State Completed
Review review-ietf-dots-signal-filter-control-04-secdir-lc-emery-2020-06-11
Posted at https://mailarchive.ietf.org/arch/msg/secdir/DbRr4JvGmZqbxPTn0yGiBTNjfaA
Reviewed revision 04 (document currently at 07)
Result Has Nits
Completed 2020-06-05
review-ietf-dots-signal-filter-control-04-secdir-lc-emery-2020-06-11-00
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?

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.

Shawn.
--