Re: [secdir] secdir review of draft-ietf-tcpm-rtorestart-08

Anna Brunstrom <> Fri, 09 October 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BDF11B421C; Fri, 9 Oct 2015 07:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJG_sK91lxFm; Fri, 9 Oct 2015 07:55:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77BBE1B4293; Fri, 9 Oct 2015 07:55:42 -0700 (PDT)
X-Spam-Processed:, Fri, 09 Oct 2015 16:55:35 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDArrival-Date: Fri, 09 Oct 2015 16:55:35 +0200
To: David Mandelberg <>,,,
References: <>
From: Anna Brunstrom <>
Message-ID: <>
Date: Fri, 9 Oct 2015 16:55:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:03 -0700
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-rtorestart-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2015 14:55:44 -0000

Hi David,

Thanks for your question. Answer inline.

On 2015-10-06 23:22, David Mandelberg wrote:
> 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 describes an experimental change to a TCP and SCTP 
> retransmission timer.
> I thought about multiple ways to attack the specified algorithm, and 
> was unable to come up with anything noteworthy. However, I should note 
> that I do not feel qualified to comment on the impact this change 
> might have on congestion in the Internet.
> The security considerations section primarily references RFC 6298, 
> which I believe is sufficient.
> As such, I think this document is Ready.
> Venturing outside my area of expertise (so feel free to disregard 
> this), I have a question about section 4, step 3a. Would it make more 
> sense for the "0" to be replaced with a configurable parameter? It 
> seems to me that the number should be close to an inter-packet arrival 
> time to more accurately avoid the issue mentioned below ("this is 
> required to ensure that RTOR does not trigger retransmissions 
> prematurely when previously retransmitted segments are acknowledged").

You are correct in that an acknowledgment for a retransmitted segment 
may result in a value of RTO - T_earliest that is larger than zero. 
However in that case the RTO will be reset anyway when the segment is 
retransmitted in response to the ACK, so it is not a problem. So using a 
value of zero is the simplest approach to solve the issue. This thread 
on the tcpm list discusses the scenario in more detail: .

Best Regards,