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

From: David Mandelberg <[email-masked]>
Date: Tue, 06 Oct 2015 17:22:06 -0400

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

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 9 Oct 2015 16:55:34 +0200

Hi David,

Thanks for your question. Answer inline.

On 2015-10-06 23:22, David Mandelberg wrote:
> 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.
>
> that I do not feel qualified to comment on the impact this change 
> might have on congestion in the Internet.
>
> 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