[Gen-art] Gen-ART review of draft-ietf-tcpm-tcp-antispoof-06.txt
Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 04 April 2007 18:38 UTC
Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZANE-0001jL-I9; Wed, 04 Apr 2007 14:38:25 -0400
Received: from gen-art by megatron.ietf.org with local (Exim 4.43) id 1HZANB-0001i7-6B for gen-art-confirm+ok@megatron.ietf.org; Wed, 04 Apr 2007 14:38:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZANA-0001hs-SR for gen-art@ietf.org; Wed, 04 Apr 2007 14:38:20 -0400
Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZAMp-0001qM-9Z for gen-art@ietf.org; Wed, 04 Apr 2007 14:38:04 -0400
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l34IbsHE030200; Wed, 4 Apr 2007 13:37:54 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 13:37:54 -0500
Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 13:37:53 -0500
Message-ID: <4613F1BC.9090809@ericsson.com>
Date: Wed, 04 Apr 2007 14:43:08 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, touch@isi.edu
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 18:37:53.0830 (UTC) FILETIME=[5B38FC60:01C776E8]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: Ted Faber <faber@isi.edu>, Lars Eggert <lars.eggert@nokia.com>
Subject: [Gen-art] Gen-ART review of draft-ietf-tcpm-tcp-antispoof-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
I am the assigned Gen-ART reviewer for draft-ietf-tcpm-tcp-antispoof-06.txt For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has a couple of issues that need to be fixed. Comments: Overall the draft is well written and has very comprehensive references of the problem and solution space(two thumbs up). Semi-substantial ================ * Page 20, this paragraph Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec can be made available [45][46]. In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path. This paragraph claims that [45] and [46] can prevent on path attackers. From my reading of [45] and [46] I understood they were designed to prevent OFF-PATH attacks and not ON-PATH attacks. I do not know if they will protect against on-path attackers. Minor ===== * Figure 1 and Figure 2 have the same column names for 'BW*delay' but the numbers are not calculated in the same way. For figure 1 it is the bandwidth delay product, but for figure 2 it is the buffer size. So I feel it would be clearer if the column was labeled simply as "Receive Window Size". * I am not convinced about the following wording in Section 2.1 "Review of TCP Windows". Send window (SND.WND): the latest send window size. I might be wrong, but in my understanding the send window size is SND.WND only when there is no unacknowledged data. If there is any unacknowledged data the send window sized is reduced to SND.WND-(size of unacknowledged data). Editorial ========= * I think a these references need to be normative RFC793, RFC2581. (HIGHLY SUBJECTIVE VIEW: Feel free to ignore) * Newer draft versions are available for the following references draft-ietf-tcpm-syn-flood-01 draft-ietf-tcpm-tcp-soft-errors-03 draft-ietf-tcpm-tcpsecure-06 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-tcpm-tcp-a… Suresh Krishnan