Reviewer: Sean Turner Review result: Has Nits 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.