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

Mirja Kühlewind <> Tue, 26 September 2017 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 989CD1331D2 for <>; Tue, 26 Sep 2017 11:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TS30vdd3kf-v for <>; Tue, 26 Sep 2017 11:46:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4222B1342FD for <>; Tue, 26 Sep 2017 11:46:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=MjHBUPQGjD7n3yZ92wnkae51tWryUGHMhlxuGCkCEYKQ6iJIT5Qzcnr1hgj5Jy0M1kmCNObLjsvtGL9+9h0dqMIfyVGJoRdichuwXYwPPnbC+WDKoTx99KTPzIVhoU7b+5yzK24T8HpIFVUslNWdMoOlf25o/Dtndp2k9n4AM84=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 8078 invoked from network); 26 Sep 2017 20:19:39 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 Sep 2017 20:19:39 +0200
To: Sean Turner <>,
References: <>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
Message-ID: <>
Date: Tue, 26 Sep 2017 20:19:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID: <>
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-tcpm-cubic-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Sep 2017 18:46:24 -0000

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.


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.