Skip to main content

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
draft-ietf-dots-data-channel-31

Yes


No Objection

(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)

Recuse


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

Warren Kumari
No Objection
Comment (2019-05-01 for -28) Sent
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) Not sent
I am the document shepherd and was the WG co-chair during the development of this draft.
Alexey Melnikov Former IESG member
(was Discuss) Yes
Yes (2019-05-09 for -29) Sent
Thank you for addressing my DISCUSS and comments.
Benjamin Kaduk Former IESG member
Yes
Yes (2019-04-02 for -28) Sent
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 IESG member
No Objection
No Objection (2019-05-01 for -28) Sent
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 IESG member
No Objection
No Objection (2019-05-02 for -28) Not sent
I did not have a chance to review this document but I am balloting No Objection on the basis of the Gen-ART review.
Alvaro Retana Former IESG member
No Objection
No Objection (for -28) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-05-01 for -28) Not sent
Alexey has this well covered, and I support his DISCUSS.
Deborah Brungard Former IESG member
No Objection
No Objection (for -28) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -28) Not sent

                            
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2019-07-22) Sent
Thanks for addressing my discuss!
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2019-05-21 for -29) Sent
Thanks for addressing my DISCUSS.