Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
RFC 8783
Yes
No Objection
Recuse
Note: This ballot was opened for revision 28 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
Thank you for writing this - I found it useful and interesting. I do have a few comments / suggestions to try improve the document further. 1: "In most cases, sufficient scale can be achieved by compromising enough end-hosts and using those infected hosts to perpetrate and amplify the attack." This is somewhat misleading - it sounds somewhat like the reflectors which get used for amplification attacks (e.g DNS servers) have been compromised. Perhaps "In most cases, sufficient scale can be achieved by compromising enough end-hosts or using amplification attacks" - in the grand scheme of things this isn't super important, but because it is so close to the beginning of the document it would be nice to set the tone correctly... 2: "After discovering the RESTCONF API root, a DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server." The commas seem superfluous, and make reading this hard. 3: "It is RECOMMENDED that DOTS clients and gateways support means to alert administrators about loop errors so that appropriate actions are undertaken." Truly a nit, but I had to reread this sentence multiple times before I got it -- I would suggest s/means/methods/ (or "provide methods"). 4: TCP flags. It is really common to match on "Established" sessions (or packets with or without the SYN flag -- I think it would be **really** helpful to describe how this is done / have an example, etc. While readers should be able to figure this out, it would be helpful to have this so people can find it in a panic. Actually, more examples in the Appendix would be generally useful... 5: "The DOTS gateway, that inserted a ’cdid’ in a PUT request, MUST strip the ’cdid’ parameter in the corresponding response before forwarding the response to the DOTS client." Extra commas...
Roman Danyliw (was No Objection) Recuse
I am the document shepherd and was the WG co-chair during the development of this draft.
(Alexey Melnikov; former steering group member) (was Discuss) Yes
Thank you for addressing my DISCUSS and comments.
(Benjamin Kaduk; former steering group member) Yes
As in the signal-channel document, there are a couple of nits in the text about using FQDNs as mitigation targets: Section 10 When FQDNs are used as targets, the DOTS server MUST rely upon DNS privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH [RFC8484]) to prevent eavesdroppers from possibly identifying the target resources protected by the DDoS mitigation service and means to ensure the target FQDN resolution is authentic (e.g., DNSSEC [RFC4034]). nits: "DNS over TLS or DoH" ("or" instead of comma, but keep the references as-is); comma before "and means to ensure", since the DOTS server has to do both of those (as opposed to the DOTS server using DoT/DoH which provides both eavesdropping protection and data authenticity, which is what the current text says).
(Adam Roach; former steering group member) No Objection
Thanks to everyone who worked on this document. Alexey covered all of my
substantive comments, and I support his DISCUSS; I only have a few editorial
nits to suggest.
---------------------------------------------------------------------------
ID Nits reports:
** There is 1 instance of too long lines in the document, the longest one
being 5 characters in excess of 72.
---------------------------------------------------------------------------
§3.4:
> its own information (e.g., server names, literal IP addresses) is
> present in the "Via" header of a DOTS message it receives:
Nit: "...header field..."
> header, the DOTS gateway MUST NOT forward the DOTS message.
Nit: "...header field..."
> error-info: <via-header> : A copy of the Via header when
Nit: "<via-header-field>...header field..."
> o Otherwise, the DOTS agent MUST update or insert the "Via" header
> by appending its own information.
Nit: "...header field..."
> DOTS client domain SHOULD remove the previous "Via" header
> information after checking for a loop before forwarding. This
Nit: "...header field..."
(Alissa Cooper; former steering group member) No Objection
I did not have a chance to review this document but I am balloting No Objection on the basis of the Gen-ART review.
(Barry Leiba; former steering group member) No Objection
Alexey has this well covered, and I support his DISCUSS.
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss!
(Suresh Krishnan; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS.