Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
RFC 9133
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
[[ questions ]] [ section 3.2.1 ] * "If not, the polling mechanism ... has to be followed". Should this use some actual 2119 language? * Is the specified client behaviour in the event of a 5.03 really MUST? That would definitely seem like recommended behaviour to me, but does it perhaps risk being over-specified to say retries without parameters MUST be attempted? I.e., should it be a SHOULD? [[ nits ]] [ section 6 ] * "entitled to access only to resources" -> "entitled to access only the resources"
Martin Duke No Objection
Murray Kucherawy No Objection
Some minor stuff only:
Section 1.1:
OLD:
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.
NEW:
A typical case is a conflict between filtering rules installed by a
DOTS client and the mitigation actions of a DDoS mitigator. Consider,
for instance, a DOTS client that 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. However,
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.
Section 1.2:
* "An augment to the DOTS signal channel ..." -- s/augment/amendment/ ("augment" isn't a thing, it's an action)
Section 3.2.1:
* Although this section declares the acronym "ACE" for "Access Control Entry", that acronym is used nowhere else in the document.
* "... notifies that DOTS client with the change ..." -- s/with/of, I think?
Section 6:
* "... does not allow to create new filtering rules ..." -- s/to create/creation of/
* "... entitled to access only to resources ..." -- s/only to/only those/
Robert Wilton No Objection
I found this document well written and easy to read and understand, particularly through the use of clear examples, so thank you. Regards, Rob
Roman Danyliw No Objection
Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review). Thanks for addressing my COMMENTs.
Éric Vyncke No Objection
Thank you for the work put into this document. I appreciated the clarity, the use of IPv6 examples, and the inclusion of the YANG model. Only one minor suggestion about the title of section 1.2 as "The Solution" looks a little marketing ;-) I would prefer "Mitigation Technique" or something more 'engineering-oriented' Regards -éric
(Benjamin Kaduk; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection