[secdir] secdir review of draft-ietf-tcpm-rfc3782-bis-03

Tom Yu <tlyu@MIT.EDU> Wed, 23 November 2011 06:59 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D04EB21F8B16; Tue, 22 Nov 2011 22:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.974
X-Spam-Status: No, score=-103.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id A5Khj3FJnQGp; Tue, 22 Nov 2011 22:59:47 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU []) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0121F852E; Tue, 22 Nov 2011 22:59:46 -0800 (PST)
X-AuditID: 1209190e-b7f4a6d0000008e5-e2-4ecc99e121f9
Received: from mailhub-auth-2.mit.edu ( []) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D1.CB.02277.1E99CCE4; Wed, 23 Nov 2011 01:59:45 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU []) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAN6xi06012238; Wed, 23 Nov 2011 01:59:45 -0500
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAN6xeed025890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Nov 2011 01:59:42 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu ( id pAN6xeY5004966; Wed, 23 Nov 2011 01:59:40 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-rfc3782-bis.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 23 Nov 2011 01:59:40 -0500
Message-ID: <ldvhb1vz5lv.fsf@cathode-dark-space.mit.edu>
Lines: 60
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6novtw5hk/g97bJhZr1kpbzPgzkdni w8KHLA7MHkuW/GTy+HL5M1sAUxSXTUpqTmZZapG+XQJXRuvvdcwFX0UqXiyfy9jAuEugi5GT Q0LARGLB2w4WCFtM4sK99WxdjFwcQgL7GCVa97exgiSEBDYwSqzbXwSRuMIk8fB3G1RVF6PE y+mr2EGqRASiJU4t+wQ2SljAQmL9/j1ANgcHm4C0xNHFZSBhFgFViW+XNjOC2LxAJU33jzOD 2DwCnBK3br5lh4gLSpyc+QRsDLOAlsSNfy+ZJjDyzUKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGusV5uZoleakrpJkZQoHFK8u1g/HpQ6RCjAAejEg9v5MnTfkKsiWXFlbmHGCU5 mJREeb1mnPET4kvKT6nMSCzOiC8qzUktPsQowcGsJMJb3weU401JrKxKLcqHSUlzsCiJ867e 4eAnJJCeWJKanZpakFoEk5Xh4FCS4A0ERpSQYFFqempFWmZOCUKaiYMTZDgP0PCDIIt5iwsS c4sz0yHypxgVpcR5VUGaBUASGaV5cL2wRPCKURzoFWFec5AqHmASget+BTSYCWjwtLUnQAaX JCKkpBoYuYM+uzQd7W19o8X6R8+w9bJNpYeJ8bb65EZdDZGb2c1+n3U6ShqLr1kdi/yw74eT /PqFEdVeJvWG0m1XSl17RVovbMu2/WQs+rxZ76tokL5Qfg1j4lXGSbcf9t0PPcccx7o91+dE XIYNb0GOatLKldM8y3utP56sPu5/5cAlh7f32OMSzZRYijMSDbWYi4oTATb7dSLfAgAA
Subject: [secdir] secdir review of draft-ietf-tcpm-rfc3782-bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 23 Nov 2011 06:59:47 -0000

The Security Considerations section of this document says:

   [RFC5681] discusses general security considerations concerning TCP
   congestion control.  This document describes a specific algorithm
   that conforms with the congestion control requirements of [RFC5681],
   and so those considerations apply to this algorithm, too.  There are
   no known additional security concerns for this specific algorithm.

I believe this assessment is accurate.


I found it really confusing where Section 4 appears to directly copy
text from RFC 3782 with no fixups of section references and step
numbers.  For example, 4.1 refers to a Step 1B of Section 3.  There is
no Step 1B in this document, and the relevant section is actually
Section 3.2.  Also, Section 4.2 refers to a Step 1A of Section 3, when
it probably means Step 2 of Section 3.2 of RFC 5681.

In Appendix B, first paragraph:

   In [RFC3782], the cwnd after Full ACK reception will be set to
   (1) min (ssthresh, FlightSize + SMSS) or (2) ssthresh.  However,
   there is a risk in the first logic which results in performance
   degradation.  With the first logic, if FlightSize is zero, the
   result will be 1 SMSS. This means TCP can transmit only 1 segment
   at this moment, which can cause delay in ACK transmission at receiver
   due to delayed ACK algorithm.

The phrase "first logic" sounds awkward, and should probably be "first
option", to align with the wording in Section 3.2.

In Appendix B, end of second paragraph:

   Even if window size is not small,
   loss of ACK packets or receive buffer shortage during fast recovery
   can also increase the possibility to fall into this situation.

should probably end with "...can also increase the possibility of
falling into this situation."

In the third paragraph of Appendix B:

   The proposed fix in this document ensures that sender TCP transmits
   at least two segments on Full ACK reception.

I initially couldn't determine exactly what changes in this document
achieve the purported fix, but I'm not an expert at TCP.  The text in
step 3 of Section 3.2 of this document is substantially the same when
describing the Full ACK behavior, and the prescribed options for
resetting the value of cwnd looked the same as in RFC 3782 until I
carefully compared them side by side.  Perhaps more clearly
identifying the change, using text like:

   The proposed fix in this document, which sets cwnd to at least
   2*SMSS if the implementation uses option 1 in the Full ACK
   behavior, ensures that sender TCP transmits at least two segments
   on Full ACK reception.

would be better.