Subject: [tcpm] Secdir last call review of draft-ietf-tcpm-cubic-06

From: Sean Turner <[email-masked]>
Date: Tue, 26 Sep 2017 07:15:22 -0700

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.

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 26 Sep 2017 20:19:38 +0200

Hi Sean,

thanks a lot for your review. These are good thoughts but after all mostly 
independent of cubic. Basically all that cubic does it that is provides an 
alternative for equation 3 in RFC5681 while all the rest of RFC5681 still 
applies and need to be implemented to have a working TCP implementation.

Moe specifically also, the ACK division attack is actually not a problem for 
cubic because it does not use SMSS in any of its equation.

In summary, while it probably doesn't hurt to point to the security 
considerations of RFC5681, I don't think it is absolutely necessary.

Mirja