Last Call Review of draft-ietf-tcpm-rtorestart-08
review-ietf-tcpm-rtorestart-08-secdir-lc-mandelberg-2015-10-08-00

Request Review of draft-ietf-tcpm-rtorestart
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-10-08
Requested 2015-10-01
Authors Per Hurtig, Anna Brunstrom, Andreas Petlund, Michael Welzl
Draft last updated 2015-10-08
Completed reviews Secdir Last Call review of -08 by David Mandelberg (diff)
Opsdir Telechat review of -08 by Tim Wicinski (diff)
Assignment Reviewer David Mandelberg
State Completed
Review review-ietf-tcpm-rtorestart-08-secdir-lc-mandelberg-2015-10-08
Reviewed rev. 08 (document currently at 10)
Review result Ready
Review completed: 2015-10-08

Review
review-ietf-tcpm-rtorestart-08-secdir-lc-mandelberg-2015-10-08

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/