Subject: [Gen-art] Gen-ART review of draft-ietf-tcpm-tcp-antispoof-06.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 04 Apr 2007 14:43:08 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art