[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