1.Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin
Kaduk. This document specifies an extension to the DOTS signal channel protocol
so that DOTS clients can control their filtering rules when an attack
mitigation is active. Particularly, this extension allows a DOTS client to
activate or de-activate existing filtering rules during a DDoS attack. The
working group has the consensus to publish it as a Proposed Standard since it
is a protocol draft, which is stable in technical aspect and gets enough
community interest to be considered as valuable.
2. Review and Consensus
The issue which led to this extension defined in the draft was found in IETF103
DOTS hackathon:
https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00.
The consensus for adopting to specification was solid. No controversial issues
was raised during the development of the document. And since then, the
specification went through many iterations to take into account the comments
from WG. Right now, two interoperable implementations are available (NTT, NCC)
and the interoperability testing (e.g., IETF104 at
https://datatracker.ietf.org/meeting/104/materials/slides-104-dots-interoperability-and-hackathon-report-00)
has justify and improve the specification.
This draft firstly proposes the identified problem which the DOTS Server cannot
modify the filtering rules by data channel during the volumetric attack, then
defines the according solution by counting on the signal channel messages. The
detailed augments to the signal channel data model and the related protocol
behaviors are also described. Besides, some examples are given at last to give
more evidence about the solution necessity and value. The overall solution is
relatively straightforward and simple.
In summary, this draft has been extensively reviewed and discussed within the
working group by mailing list and github, and I believe all technical issues
raised have been resolved till this version (-02).
3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79. There are no IPR
disclosures on the document. See: * Kaname:
https://mailarchive.ietf.org/arch/msg/dots/sVkZIxf_0eWXCFMmJCMGuzwEjd0 *
Med: https://mailarchive.ietf.org/arch/msg/dots/KWlaAg5r8bqRxTch99NBqbugyQQ *
Tiru:
https://mailarchive.ietf.org/arch/msg/dots/l_UFT1A0gUk5acHA6fPNEGWOOzE *
Takahiko: https://mailarchive.ietf.org/arch/msg/dots/WuVe0246nJlbhbWeRm2yy5zBfoY
4. Other Points
By performing the idnits check, there are no problem.
In general, I believe the IANA Considerations are clear and ready. There are
totally 2 IANA requests:
1) one added 'activation-type' parameter in the existing DOTS signal channel
CBOR mappings registry 2) a new URI in "IETF XML Registry"
(urn:ietf:params:xml:ns:yang:ietf-dots-signal-control) for a new "YANG Module
Names" registry (ietf-dots-signal-control);
No early expert review has been requested for the above IANA allocation.