Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

This document specifies a TCP congestion control algorithm.  It
uses a cubic function instead of linear window increase function.
It is the default function for Linux.

It's ready with nits - basically a couple of more words the security
considerations and maybe a reference or two and you’re done.

Note: I know next to nothing about congestion control functions
so I'm going to trust the function is properly specified and reflects
what's actually implemented.

The security considerations were a little bit terse.  So here's a couple
of questions that came to mind while searching around for where
to refer:

1. I get that since CUBIC just changes the congestion window
adjustment function on the sender side that it makes "no
changes" to the underlying security of TCP.  But, I kinda had to
guess where the underlying security of TCP are documented -
so how about adding "[RFC5681]" to end the sentence assuming
that's where the security considerations for TCP are documented.

2. I think the answer is yes here, but wanted to check:
In RFC5681's security considerations, there's some text
about how to deal with the "ACK division attack" by:

   ... increasing the congestion window based on the
   number of bytes newly acknowledged in each arriving ACK
   rather than by a particular constant on each arriving ACK (as
   outlined in section 3.1).

CUBIC has protections against this attack because it MUST
support slowstart?  Like I said, I think it's yes because s3.1 in
RFC5681 is all about slowstart.

WRT s5.1: In (quickly) reviewing SACK it refers to RFC5961
(aka dealing with the blind in-window attack), does CUBIC
protect against this attack?  If it does or doesn't it might be
worth an informative reference to RFC5961 in s5.1 because
it was published after RFC5681.