Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification

Note: This ballot was opened for revision 28 and is now closed.

Benjamin Kaduk Yes

Comment (2019-04-02 for -28)
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  

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

(Alexey Melnikov) (was Discuss) Yes

Comment (2019-05-09 for -29)
Thank you for addressing my DISCUSS and comments.

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Comment (2019-05-02 for -28)
No email
send info
I did not have a chance to review this document but I am balloting No Objection on the basis of the Gen-ART review.

(Suresh Krishnan) (was Discuss) No Objection

Comment (2019-05-21 for -29)
Thanks for addressing my DISCUSS.

Warren Kumari No Objection

Comment (2019-05-01 for -28)
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...

(Mirja Kühlewind) (was Discuss) No Objection

Comment (2019-07-22)
Thanks for addressing my discuss!

(Barry Leiba) No Objection

Comment (2019-05-01 for -28)
No email
send info
Alexey has this well covered, and I support his DISCUSS.

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2019-05-01 for -28)
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.



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

Roman Danyliw (was No Objection) Recuse

Comment (2019-05-01 for -28)
No email
send info
I am the document shepherd and was the WG co-chair during the development of this draft.