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
On 26.09.2017 16:15, Sean Turner wrote:
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.