Skip to main content

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

Yes


No Objection

Alvaro Retana
(Deborah Brungard)
(Ignas Bagdonas)

Recuse


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

Alvaro Retana No Objection

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

Roman Danyliw (was No Objection) Recuse

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

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

(Benjamin Kaduk; former steering group member) Yes

Yes (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  
   [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

No Objection (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.

---------------------------------------------------------------------------

§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

No Objection (2019-05-02 for -28)
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

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

(Deborah Brungard; former steering group member) No Objection

No Objection (for -28)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -28)

                            

(Mirja Kühlewind; former steering group member) (was Discuss) No Objection

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

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

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