Re: [secdir] secdir review of draft-ietf-tcpm-rtorestart-08
Anna Brunstrom <anna.brunstrom@kau.se> Fri, 09 October 2015 14:55 UTC
Return-Path: <prvs=072417ea0b=anna.brunstrom@kau.se>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF11B421C; Fri, 9 Oct 2015 07:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJG_sK91lxFm; Fri, 9 Oct 2015 07:55:42 -0700 (PDT)
Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BBE1B4293; Fri, 9 Oct 2015 07:55:42 -0700 (PDT)
X-Spam-Processed: mail.kau.se, Fri, 09 Oct 2015 16:55:35 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDRemoteIP: 193.11.155.133
X-MDArrival-Date: Fri, 09 Oct 2015 16:55:35 +0200
X-Authenticated-Sender: anna.brunstrom@kau.se
X-Return-Path: anna.brunstrom@kau.se
X-Envelope-From: anna.brunstrom@kau.se
To: David Mandelberg <david@mandelberg.org>, iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-rtorestart.all@tools.ietf.org
References: <08c33803c2e1397c9467ad269bc55edc@mail.mandelberg.org>
From: Anna Brunstrom <anna.brunstrom@kau.se>
Message-ID: <5617D566.50408@kau.se>
Date: Fri, 09 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: <08c33803c2e1397c9467ad269bc55edc@mail.mandelberg.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/AEbNvUhPCfJwDrftKFOws3fR9io>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:03 -0700
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-rtorestart-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: 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: http://www.ietf.org/mail-archive/web/tcpm/current/msg09179.html . Best Regards, Anna
- [secdir] secdir review of draft-ietf-tcpm-rtorest… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-tcpm-rto… Anna Brunstrom