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

Mirja Kühlewind <ietf@kuehlewind.net> Tue, 26 September 2017 18:46 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989CD1331D2 for <secdir@ietfa.amsl.com>; Tue, 26 Sep 2017 11:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS30vdd3kf-v for <secdir@ietfa.amsl.com>; Tue, 26 Sep 2017 11:46:22 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4222B1342FD for <secdir@ietf.org>; Tue, 26 Sep 2017 11:46:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; 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 nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 Sep 2017 20:19:39 +0200
To: Sean Turner <sean@sn3rd.com>, secdir@ietf.org
Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-cubic.all@ietf.org
References: <150643532230.20822.2899916825960257300@ietfa.amsl.com>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>
Message-ID: <f799c070-0867-2db0-033d-0527d5dc8dcf@kuehlewind.net>
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: <150643532230.20822.2899916825960257300@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID: <20170926181939.8070.26405@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DXQTbtovYaXUaQ8SnKAqN8Soxxs>
Subject: Re: [secdir] Secdir last call review of draft-ietf-tcpm-cubic-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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.

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