1. Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin
Kaduk. This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of-Service (DDoS)
attacks to a server capable of enabling network traffic mitigation on behalf of
the requesting client. 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 enjoy enough community interest to be considered valuable.
2. Review and Consensus
The -00 version of this WG draft has been submitted in 2017-04, and it has fast
evolved into its -25 version now. The co-authors are from some of the leading
vendors and operators in DDoS protection industry with extensive experience
with the related technologies and implementations, they are also the core
authors of the DOTS requirements WG drafts which guarantee their consistency.
Until now, there are three demo implementations for it (open source go-dots
from NTT, two proprietary demos from NCC and Huawei) and several rounds of
interop test during IETF hackathon activities. All the technical issues
identified by these demos and the finished tests have been addressed and
reflected into the latest draft, which are very helpful for the completeness
and quality improvement of the draft.
This draft firstly specifies the DOTS signal channel messages and the related
behaviors (e.g., DOTS mitigation management messages: request, status exchange,
withdraw, DOTS signal channel session configuration messages, redirection and
heartbeat messages), then defines all the signal channel messages format with
YANG data model and their mapping CBOR scheme. Besides, other related issues
are also discussed (e.g., (D)TLS protocol profile and AA). Among them, several
topics may need further review because of the complexity or importance: * The
definition of 'cuid', 'cdid' and 'mid' parameters for DOTS client/client domain
identity and mitigation session, as well as various means of using them
together; * the conflict resolution mechanisms for the mitigation request
messages with the overlapping mitigation scope, which can be sent from the same
DOTS client or different DOTS clients; * DOTS heartbeat mechanism and the
related NAT traversal consideration; * DOTS messages YANG data model, and the
corresponding CBOR schema mapping.
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 (-25). So, the latest document is
well written and reaches a broad consensus in WG.
3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79. There are no IPR
disclosures on the document.
4. Other Points
By performing the idnits check, there are just one minor problem (the
referenced WG draft has been updated to next version).
In general, I believe the IANA Considerations are clear and ready. There are
totally 4 IANA requests: 1) a service port number (4646); 2) a new Well-Known
URIs registry (dots); 3) a new URI in "IETF XML Registry"
(urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel) for a new "YANG Module
Names" registry (ietf-signal); 4) the initial DOTS signal channel CBOR mappings
registry and the registration template for new CBOR mapping
No early expert review has been requested for the above IANA allocation.