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

[Mirja Kühlewind <[e-mail]>]

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.
>