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. --