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/